Comment by alecco
11 years ago
And the matching rule: badly designed projects that blow up end up getting a lot of attention and resources, their engineers end up looking like heroes.
I remember the worst module of a very large J2EE website getting all the attention, got more developers, got 10x more hardware than planned... And in the end the lead was promoted. While several other modules did their work flawlessly and went unnoticed.
This is what you get when business people make decisions on technology projects.
From 'Software Requirements & Specifications' [0], by Michael Jackson (not that Michael Jackson, and not the other one either), published in 1995, a parable [1]:
'What do you think?' he asked. He was asking me to tell him my impressions of his operation and his staff. 'Pretty good,' I said. 'You've got some good people there.' Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.
'What did you think of Fred?' he asked. 'We all think Fred is brilliant.' 'He's very clever,' I said. 'He's not very enthusiastic about methods, but he knows a lot about programming.' 'Yes,' said the DP Manager. He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. 'Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it.' His voice dropped to a reverent hush. 'Fred tells me that he's not sure he understands it himself.'
'Terrific,' I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. 'But what about Jane?' I said. 'I thought Jane was very good. She picked up the program design ideas very fast.'
'Yes,' said the DP Manager. 'Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet --- if you see what I mean?'
I saw what he meant.
[0] http://www.amazon.co.uk/Requirements-Specifications-Software... [1] http://www.win.tue.nl/~wstomv/quotes/software-requirements-s...
I've noticed over the course of my career a fairly severe corollary, which is that making the best technical choices for my employer can often be bad for me in the long run.
As an example, for about the last 10-15 years, I've tended to choose Python over C++, for projects where it seemed it would produce a better solution (e.g., cheaper/faster to implement, easier to maintain and alter, performance sufficient to the task at hand). Because Python is actually quite adequate these days for large swaths of the task space, this means that my Python chops are quite good, but that my C++ is a little rusty.
In itself, this isn't exactly a problem, but in an interview scenario, it can look quite bad. "How much template metaprogramming have you done lately?" "Not much." "So, you're more of a junior programmer then?" "No, I just haven't hit a problem lately that needed that, and I prefer not to introduce unneeded complexity and maintenance nightmares into my employer's codebase." "How much work with GDB automation?" "Very little, since the code I write pretty much just works." "Ah, so weakness with the debugger as well." Etc.
Not really sure what to do about this. I don't really want to write tens of thousands of lines of unnecessary C++ just to impress future employers. But I have to acknowledge that that's really how the rewards are set up.
This dynamic is part of why I feel like programmers should really just stop resisting the pull to move into management. You might think about programming as the most amazing thing ever, to be agonized over with a fine-toothed comb and the 'best tool for the job' elevated to a nigh-religious consideration, but to your employer, it's one line item on a budget.
3 replies →
Rebrand yourself as a python developer.
I know you might not want to hear that, but you'll probably find much more enjoyable employment anyway.
1 reply →
Work for people who are more concerned with the business value you provide and how fast, and reliably you provide it, and who don't care about the details of what technology you use.
This often means being hired by the CEO and not the CTO.
If you liked that, you should definitely read The Parable of the Two Programmers:
http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...
The main thing I read in this parable is the intense focus on comparing individuals and putting them at odds, instead of working to find the best way they can work together in a good system.
What's the core problem there? Why do people think in this way, instead of more systematically? What's the intention and what are the assumptions? Many questions raised.
I'll try to address a few points here:
-What's the core problem?
Evaluation. In this case, evaluating intrinsic difficulty of a certain task or group of tasks. There's no way to do so systematically, without inside knowledge about the task. Foe example, suppose you want to rank two mathematicians without a clue about the subject matter. One presents short proofs to many problems, while the other presents enormous proofs with great effort. There's no way to tell if the problems are really difficult or not and chose the reward without having knowledgeable peers evaluate the a) hardness, and b) usefulness intrinsic to the problem. In fact, it could be argued that simplicity is a good sign, but it's impossible to tell whether the problem is unimportant/trivial to begin with.
- Why do people think in this way, instead of more systematically?
Without insider knowledge, which management sometimes lacks, you cannot confidently rank as stated above. But there's one trivial thing you can do, which works, but not necessarily efficiently: if the solution works/is found, reward the solver, otherwise punish/look for others (and reward them more). Hard problems skillfully solved will go unrewarded and good performers will gravitate towards fixing crisis instead of doing good ground up engineering as they should. That's the aspect of inefficient, but it is possible with enough money to manage this way.
3 replies →
Is this book worth buying?
Great story. Reminds me of
"Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." - Alan Perlis
Along similar lines:
"Make things as simple as possible, but not simpler." -Albert Einstein
I just saw this in the last project in my company: One group delayed the difficult decisions until the last moment and had to work nights and weekends to catch up. All other groups were on top of things and done way before the deadline.
Guess which group saw promotions and gets recognized by senior management at pretty much every meeting?
Seems the best strategy is to create problems and then fix them in the most visible way.
I agree with your comment except the last sentence. Engineers also value heroics, so it's unfair to lay the blame at the feet of 'business people'. Plenty of tech startups exhibit this pattern long before there are 'management types' around.
If you read the original article in full, it covers this type of situation quite well. This is true: both employees and managers believe the blame and the heroics go to individuals, and this is a fundamental attribution error.
The vicious cycle caused by this attribution error drives companies into holes as they continue to reward and punish the wrong people for the wrong reasons.
In reality, most problems in work are systemic, and the only solutions are systemic as well. You want to create an environment where both 'business types' and employees alike are on the same wavelength about this fact, and work to improve the system they're in continuously. This is how you achieve quality, period.
I completely agree with you and I normally describe it in terms of creating the right culture (aka systemic behaviours). I've yet to read the article in full but will make time for it.
But it's easier to make business believe it's just a hard problem instead of incompetent people in charge of the solution.
The same way the police describe uncaught criminals as smart and dangerous.
>This is what you get when business people make decisions on technology projects.
I would rephrase the conclusion: This is what you get when people make emotional decisions on something.
It doesn't matter if it is a technology project or not, it is just an emotional response. There are some professional categories (doctors, funeral or wedding businesses, churches, etc) that exploit this weakness. When people are emotional charged, they don't think about the unrealistic prices of some treatments or services, they are even happy to pay them. Without this emotional charge, they would bargain and complain about it.
What are some good strategies to avoid this problem (asking as an engineer looking upwards to management)?
There is only so much you can not know about what your people do. And try to hear the people in the trenches, not their PM with slideshows.
It's not just "business people". This was published the same year as the Agile Manifesto. We know which route developers chose.
> This is what you get when business people make decisions on technology projects.
I think this is a problem with people in general, not just business people. There is a huge amount of psychological literature on biases and one of the things I find most interesting about it is that even if you're aware of a bias your thinking is still affected by it.
That's a variant of "there's no such thing as bad exposure".
When the person with the fubared project gets his daily beating from the big shots, eventually he'll figure out how to look like a hero while blaming everyone else.