Report from Management: Programmers don't know how to develop software(esciencenews.com)
esciencenews.com
Report from Management: Programmers don't know how to develop software
http://esciencenews.com/articles/2008/05/19/software.designers.strut.their.talent.cost.profit.says.management.insights.study
6 comments
I think their statement (of developers acting for their own personal good) is overblown and shows a lack of understanding of software development. It's a reactionary publication predicating on the fears of not being agile enough in the new software development world.
The proof:
Their suggestions of using better metrics on development practices of the software being built. Which is a ridiculous suggestion for anyone well vested in the literature of practical, real-world software engineering. Measuring software development is inherently difficult. What will you measure? lines of code? number of functions written? bugs fixed? All of those are ridiculous and fail at any number of different approaches to software development (and are all easily gamed). The problem is that there isn't a sure-fire way to measure how well a developer is doing without someone well experienced/knowledgeable walking through and checking everything At which point, what would be the reason for having that person develop the software to begin with?
All that can come of this study are managers in corporations reacting to suggestions of improvements in software projects from good developers by shutting them down.
This will, in effect, make those corporations slower and less productive than any sensible startup, accomplishing the exact opposite of what they want.
Yet my biggest qualm with this report, though, is the implication that it is a bad thing that developers are trying to become better with new/more complex technology! It's in the interest of all IT departments to nurture growth of their workers. While the comparison isn't exact, it would be like a pro-sports team saying it's a bad thing their players are trying to become really good.
From a tin-foil hat perspective: this was funded by YC to create more hackers dissatisfied with their jobs and go form startups!!!
Their suggestions of using better metrics on development practices of the software being built. Which is a ridiculous suggestion for anyone well vested in the literature of practical, real-world software engineering. Measuring software development is inherently difficult. What will you measure? lines of code? number of functions written? bugs fixed? All of those are ridiculous and fail at any number of different approaches to software development (and are all easily gamed). The problem is that there isn't a sure-fire way to measure how well a developer is doing without someone well experienced/knowledgeable walking through and checking everything At which point, what would be the reason for having that person develop the software to begin with?
All that can come of this study are managers in corporations reacting to suggestions of improvements in software projects from good developers by shutting them down.
This will, in effect, make those corporations slower and less productive than any sensible startup, accomplishing the exact opposite of what they want.
Yet my biggest qualm with this report, though, is the implication that it is a bad thing that developers are trying to become better with new/more complex technology! It's in the interest of all IT departments to nurture growth of their workers. While the comparison isn't exact, it would be like a pro-sports team saying it's a bad thing their players are trying to become really good.
From a tin-foil hat perspective: this was funded by YC to create more hackers dissatisfied with their jobs and go form startups!!!
You assume that new technology is necessarily more complex. This is counter to the recent trend emphasising simplicity and developer ease-of-use in development tools.
How is the title of this submission related to the content? The article is about research on counterproductive motivations of software designers. There's nothing like the phrase "don't know how" in the article at all.
Many software designers intentionally create unnecessarily complex products that do less to serve their companies and customers than to advance their careers.
Many software managers intentionally create unnecessarily complex projects that do less to serve their companies and customers than to advance their careers.
Breaking news: people sometimes act in their own interests.
Many software managers intentionally create unnecessarily complex projects that do less to serve their companies and customers than to advance their careers.
Breaking news: people sometimes act in their own interests.
Whether or not the suggested courses of action have any merit is not going to be a constructive debate, but the problem is real. People who really know what they're doing come up with the simplest solutions. Almost every time I've had someone suggest a really complicated solution to a problem (or been tempted to build one myself), I've found that after further thought there is a better way. In the few instances I've plowed forward, I've regretted it later.
The simplest solution is almost always the best one.
The simplest solution is almost always the best one.
I especially liked the suggested fixes - pay programmers for completing projects and "have product designers receive evaluations from managers who have an interest in the design projects succeeding and an excellent understanding of the technology."
If the latter is a change for a given organization, it's unlikely that overly complex software is their biggest problem or that eliminating it is possible or will make a difference.
If the latter is a change for a given organization, it's unlikely that overly complex software is their biggest problem or that eliminating it is possible or will make a difference.
Apparently management researches believe that what's really costing software development projects are that the talented developers are making too complex software! The only logical reason: because programmers are evil and only think of themselves. Management's solution: make pay based on short term software development metrics (because you can measure software development, after all!), and force talent to dumb down the complex solutions.