easy road at the expense of performance
-
It's so irritating when developers say something can't be done because it will mean more work for them even when they know that 30 minutes of changes will make a huge performance boost
-
It's so irritating when developers say something can't be done because it will mean more work for them even when they know that 30 minutes of changes will make a huge performance boost
-
Amen, happens all the time here. There's only 4 real developers on my team, and one guy lives by this mantra. Oh and he doesn't document either.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
Quit talking about me :)
It was broke, so I fixed it.
-
Quit talking about me :)
It was broke, so I fixed it.
-
It's so irritating when developers say something can't be done because it will mean more work for them even when they know that 30 minutes of changes will make a huge performance boost
It is so irritating when developers fixate on some trivial aspect of an application which has absolutely no chance of impacting the overall performance of application regardless of any performance improvements. Even worse when they claim that something is slow but can't actually demonstrate that they have in fact measured it. And even after it is pointed out that it will not impact the application, and that they haven't measured it, they still spend hours or days (certainly never minutes) 'fixing' it while ignoring the real business driven requirements that must be implemented.
-
It's so irritating when developers say something can't be done because it will mean more work for them even when they know that 30 minutes of changes will make a huge performance boost
It is an attitude I actively stamp out of the teams, when found there is very little you can do except remove the developer, it is a basic mind set, the opposite of can do! What pisses me off is the opposite, a user complains about an extra click and a junior dev spends 5 days trying to hack a solution. We have a major need to identify trivial requests and filter them for priority, this is very difficult when the users have direct access to the devs without a BA in the loop.
Never underestimate the power of human stupidity RAH
-
It is an attitude I actively stamp out of the teams, when found there is very little you can do except remove the developer, it is a basic mind set, the opposite of can do! What pisses me off is the opposite, a user complains about an extra click and a junior dev spends 5 days trying to hack a solution. We have a major need to identify trivial requests and filter them for priority, this is very difficult when the users have direct access to the devs without a BA in the loop.
Never underestimate the power of human stupidity RAH
I usually just focus on what needs to be done. On occassion, I will find something that could use improved performance (whether it is known to need it or not) and improve it. For example, I spent a good chunk of time the other day improving a SQL string splitting function that had O(N^2) performance and made it O(N). I figure that I spend such a small fraction of my time doing that that it shouldn't matter to my management.
Martin Fowler wrote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
-
It is an attitude I actively stamp out of the teams, when found there is very little you can do except remove the developer, it is a basic mind set, the opposite of can do! What pisses me off is the opposite, a user complains about an extra click and a junior dev spends 5 days trying to hack a solution. We have a major need to identify trivial requests and filter them for priority, this is very difficult when the users have direct access to the devs without a BA in the loop.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
the users have direct access to the devs without a BA in the loop.
yeah - I have suffered with that in the past. Ended up telling the developers that they were to politely note any requests for changes, but tell the user that I had told them that they must not spend any time implementing user's requests that didn't come through me, on pain of death. The devs were also told that I would make them undo any changes that were not requested through the proper channels, and would not pay them for the time either to implement or remove said changes. Then I stuck to my guns for a week or two and handled the flak. Management meetings were a ball! Manager: "One of my users just asked that this button be made the same size as all the other buttons, surely that would onlny take five minutes, but now we're being told we have to follow some procedure! It's ridiculous!" Me: "You're right, it is ridiculous! If you'd just confirm that I can take the developer off this other project for, say, half a day to make the change, test it, have the change reviewed etc. then we can do it. It's sad that we get so many requests like this that I just don't have the manpower to handle! If only we could persuade the MD to increase my staff by at least one developer, I could assign them permanently to making minor changes like this. By the way, what cost have you estimated against not making the change? Oh, and do all the users agree on the size change? I believe one of your staff actually requested it be made smaller originally? Were they wrong, or should we implement some user-preferred button size?" It's a verbose way of saying **** off, but seemed to work!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
Mycroft Holmes wrote:
the users have direct access to the devs without a BA in the loop.
yeah - I have suffered with that in the past. Ended up telling the developers that they were to politely note any requests for changes, but tell the user that I had told them that they must not spend any time implementing user's requests that didn't come through me, on pain of death. The devs were also told that I would make them undo any changes that were not requested through the proper channels, and would not pay them for the time either to implement or remove said changes. Then I stuck to my guns for a week or two and handled the flak. Management meetings were a ball! Manager: "One of my users just asked that this button be made the same size as all the other buttons, surely that would onlny take five minutes, but now we're being told we have to follow some procedure! It's ridiculous!" Me: "You're right, it is ridiculous! If you'd just confirm that I can take the developer off this other project for, say, half a day to make the change, test it, have the change reviewed etc. then we can do it. It's sad that we get so many requests like this that I just don't have the manpower to handle! If only we could persuade the MD to increase my staff by at least one developer, I could assign them permanently to making minor changes like this. By the way, what cost have you estimated against not making the change? Oh, and do all the users agree on the size change? I believe one of your staff actually requested it be made smaller originally? Were they wrong, or should we implement some user-preferred button size?" It's a verbose way of saying **** off, but seemed to work!
MVVM# - See how I did MVVM my way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
_Maxxx_ wrote:
"One of my users just asked that this button be made the same size
We have forcibly injected the BA into the change process somewhat like you have done, worked wonders for productivity. They were also physically located between the devs and the users so the users had to run the gauntlet of the BAs, that was funny! Now we have been relocated, the dog boxes are smaller and the BAs have been shoved off to a corner, I predict productivity declines across the board!
Never underestimate the power of human stupidity RAH
-
Amen, happens all the time here. There's only 4 real developers on my team, and one guy lives by this mantra. Oh and he doesn't document either.
"I have a theory that the truth is never told during the nine-to-five hours. " — Hunter S. Thompson
I told the guys we working with that we need a common customer details table because they have like 7 tables for different types of customers each with similar fields. Because they'd have to rewrite a bit of their code they saying it's not possible. The db is still empty because dev has just started
-
I told the guys we working with that we need a common customer details table because they have like 7 tables for different types of customers each with similar fields. Because they'd have to rewrite a bit of their code they saying it's not possible. The db is still empty because dev has just started
A good solution for this is to create a the common table, then create views with the same names and columns as the original tables. The database structure gets fixed, no code gets broken. You can then pick through any code referencing the views and point them to the proper table at your leisure.
-
_Maxxx_ wrote:
"One of my users just asked that this button be made the same size
We have forcibly injected the BA into the change process somewhat like you have done, worked wonders for productivity. They were also physically located between the devs and the users so the users had to run the gauntlet of the BAs, that was funny! Now we have been relocated, the dog boxes are smaller and the BAs have been shoved off to a corner, I predict productivity declines across the board!
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
the dog boxes are smaller
Did you just refer to your cubicle as a dog box? +5 for that.