One of the things that I did down in Silicon Valley was attend a lecture by Alan Cooper, notable for his authorship of the book About Face in 1995 and his criticism of exposing the hierarchical file system and the RAM/disk distinction to end-users. Cooper’s latest project is “ending the death march”, figuring out how to fix the chronically broken process of software development. Cooper starts from the proposition that software development projects are opaque to management, generally failures, and therefore management underfunds and understaffs them, hoping that, if failure is inevitable, at least it will be a cheaper failure.
Cooper wants to see interaction design, the software’s behavior, made more explicit in the design. He notes that he has met two kinds of programmers in this world: (1) those who like to get stuff right, and (2) those who like to ship product and get it into users’ hands. His proposal is “the Triad” in which three kinds of people are given equal status on the project: Interaction Designers, Design Engineers, and Production Programmers. The design engineers figure out how to get state of the art technology and algorithms into the product and they may write a lot of test code that will eventually be chucked. The production programmers handle all of the edge cases and compatibility/installation/deinstallation concerns. He presented a lot of graphs for CEO-types about measuring return on investment at various stages. I didn’t understand these.
I personally enjoyed seeing Cooper’s elevation of interaction design. In the course that we teach at MIT, we try to hammer into students the importance of planning the data model (what can be represented in between clicks and sessions) and page flow (the interaction design itself) before writing the pages. For all too many systems, the interaction design is only specified implicitly in a huge pile of CGI scripts or whatever.
The question for commenters is “Do we believe that changing the management process can fix software development?”
Let’s look at some potential arguments against Cooper’s proposal.
First, it is unclear that the average software project is underfunded or understaffed. The U.S. govenrment regularly throws $billions at seemingly fairly simple software projects that a handful of expert programmers ought to be able to do by themselves. A typical project has lots of mediocre programmers on it whose contributions are negative. In this sense, the project is clearly overstaffed because it would go faster if you fired 50 percent of the people.
Second, the fundamental tools and debuggers for software have changed but little in 50 years. During that time, many tens of thousands of organizations have executed software development projects. Among these tens of thousands of organizations, every conceivable management structure has already been tried. If there were a silver bullet, it would already have been discovered by one of these companies, perhaps randomly, and then propagated to the world at large.
Third, when genuine progress has been made in software development productivity and software quality, it has come from improved tools such as SQL (a declarative language that replaced a lot of unreliable and unreadable imperative code). Maybe the reason software development projects fail is that we’re using the same tools, the programmers have the same IQ as in decades past (or perhaps lower as the smart ones trot off to professional schools), and the requirements have become more complex.
Fourth, when you see a company whose products are better than competitors, it is usually because they have programmers with higher IQs, not a magic management technique. Google has the smart people; the federal government (and its contractors) has the dullards. Google gets innovative stuff out on time; the federal government ends up years behind schedule on a simple rewrite.
Fifth, over the life cycle of a software product, we already almost have the kind of structure and division of labor proposed by Cooper. The programmers who like blazing new trails, albeit somewhat sloppily, show up on Day 1. They solve the hardest algorithm problems and get a working v1.0 out the door. By the time v3.0 is shipped, natural turnover within the development group has resulted in the code being worked on only by production programmers who like methodically sweating the details.
Some arguments in favor of Cooper’s proposal:
Managers of software development projects tend to be so incompetent and lacking in information that they can’t recognize and reward the strong contributors (this results in the best programmers getting paid only 20-30 percent more than the mediocre ones (compared to a 500 percent ratio in most areas of law, for example)).
Making the interaction design explicit makes it easy for decision-makers to evaluate whether programmers are accomplishing anything.
“…tools and debuggers for software have changed but little in 50 years.”
I disagree with this. Progress has slowed since the mid ’80s (at best, we’re still at the Lisp Machine level). But high level languages and interactive (vs. batch) programming were significant advances. The plateau was hit 20-25 years ago, not 50.
As Fred Brooks points out in “The Mythical Man Month”, the final major advance is the availablity of off-the-shell software. For the vast majority of people, this eliminates the need to develop software in the first place.
To say that tools and software have changed little over the last 50 years is overstating it to say the least. The old timers who regale me with stories of punchcards and time-sharing mainframes certainly think a few things have changed for the better.
Also Google’s contributions are great, but overstated. They get stuff out on time? On who’s timetable? It’s not like anyone knows if they slip. Who’s measuring them? They’re not contracted by anyone to complete anything by a certain timetable as far as I can tell. And if everyone could release everything in beta form for one country, then I’m sure a lot more software companies would have an easier time too. I’m not trying to berate Google (they’re unbelievable company), but just provide another perspective to balance things out.
However, that’s not the say Alan has no point. Management and programmer incompetence IS a big issue…but is that different from any other field? Even given the complexities inherent in modern software projects, many are much worse off than they need be.
One other point I’d like to add — the lives of programmers who answer to non-programmers is far different from the lives of programmers in organizations run by engineers. Organizations run by good programmers understand that seemingly simple changes can have huge impacts and so will only suggest them if they are really needed. Organizations run by programmers will understand the need to plan things out and they’ll understand that just because you aren’t at a computer typing code, that doesn’t mean you aren’t being productive. They can understand the need to cut a feature to meet a deadline because they’ve been there themselves. These are alien concept to most people( programmers included, sadly ).
“Cracking the whip” may get a little more productivity out of you, but there are only so many finite actions one can make in one day. No matter how great your team or how much money you have, you won’t build Amazon.com in 3 months, regardless of how simple these things may appear to a non-programmer on the outside. It’s just a couple of webpages right? Use Frontpage and connect it to a Access! This kind of thinking is often what passes for “design”.
On your first point, I would say it’s not that projects are underfunded/staffed, it’s that they are pressured to perform faster than is possible/prudent, and everything suffers when development managers lack the spine and skill to push back.
On your fourth point, the problem is more that software dev. management decisions are rarely made by managers. Good build processes, iterative vs waterfall development, and upfront design are all management choices, and just as critical as smart programmers to success, but they’re typically snuck in by programmers. I’ll ignore the lucky few who have managers that were/remain good programmers.
Separating the technical/development aspects of management from the traditional parts of the job into a parallel chain of management is a significant change in software management that’s gotten pretty widespread in the last few decades. A big difference at Google seems to be that the technical managers have a lot more power than they do at other companies.
Phillip,
Interesting topic but your choice of sample cases is bit dumb. Google doesn’t perform any service which they have to be reliable nor compliant with any existing norms. Also they don’t have to bother much with legacy systems and other oddities of the real world.
Try next time to pick samples from the financial world where there are incredible preasures and changing requirements as the project moves not to mention the wornderful legacy systems. In that environment even smart developers and manager can’t make headways some times, not to mention deliver!
Regards,
Sergio
Philip,
One – a small group of smart people CAN accomplish great feats, however they must either limit their project, or limit the documentation of their project. When you want to have a large project AND documentation of it, you are doomed to carry a large staff of people, all of whom are not ‘smart’. That’s just the way life is and this problem (which is faced by the government mainly due to the scope of projects and expectation of documentation) can only be moderately alleviated by good communication, effective project management etc…
Two – Tools -r- tools, it seems that the more ‘modern’ the tools that I use, the more primitive their interfaces (i.e. Back to command-line). However, most of the work that I do is in a larger framework, such as an existing application, that requires interfaces or modifications. in these cases, I have access to API’s and decades of prior work to draw from.
Three – Not only are the requirements more complex, but the existing applications represent decades of effort, by people that are waaay smarter than me.
Four – I kinda disagree with you here… Goes to the Joke, ‘How did god create everything in six days? No Legacy Code!’. But really, comparing the rapid moves of a start-up to any entrenched organization is unrealistic.
Five – I love blazing trails, our main vendor dumps three or four really unique opportunites at our feet every year, I actually have the time (directly and through staff) to apply a slightly smaller number of these techniques to our real problems… Maybe I am too ‘Hands On’, but I feel really guilty if I spend my whole week playing with new toys and dump the grunt work off on my ‘fastidious programmers’.
My scenario looks like thisBusiness People want solutions rapidy in order to gain market advantage, save money, look effective for their next review, etc…. IT people want to be able to maintain what is running, recover from errors avoid killing clients through software bugs, etc…This creates a working environment for staff that managers of software development projects MUST deal with… If I had my druthers, I would train my end users to be business analysts, my business analysts to be programmers and my programmers to be end users… As it stands, my end users speak in vague terms, and only ‘discover’ their real requirements when the new applications doesn’t fit their expectationsMy business analysts are more than happy to hot-potato design documents off to the developers in order to show their boss a fast turn-aroundand my developers (all good-hearted souls), get stuck doing analysis (over), coding applications, and finalizing many requirements on the implementation side of the job (instead of during project scoping).
Right now, I would be happy if I had two more programming positions (an increase 30%) and responsibility for performing all analysis.
1. I love it when university types ponitificate on software development in the real world. And I have read Cooper’s texts, and it makes perfect sense if you exist in the world of Cooper.
2. Comparing Google (or any other recent company that got started in the post-www world) to government or existing corporate behemoths is absolutely ridiculous. Government and companies are dealing with critical business function code bases that may be 20-30 years old or older, and the systems keep exponentially spawning to hook in and/or lay on top of the existing spaghetti. Companies that had a reserve of technical expertise are run by skeleton crews who farm work out to offshore vendors and/or rent-a-coders.
3. Tools have gotten better but the complexity of interlocking environments and fed/supplied systems, along with the proliferation of platforms has kind of offset gains here. Better unit testing, but n*n more connections means more bugs and misunderstandings and points of failure.
4. Best management strategy IMV is to procure excellent programmers and QA folks and let them do their thing, removing bureaucratic obstacles from their path.
“The U.S. govenrment regularly throws $billions at seemingly fairly simple software projects that a handful of expert programmers ought to be able to do by themselves. A typical project has lots of mediocre programmers on it whose contributions are negative. In this sense, the project is clearly overstaffed because it would go faster if you fired 50 percent of the people.”
Well Phil, if you really feel the Fed contracting jobs can be done with signifigantly less manpower you are wasting your time encouraging the upcoming entrepeneurs to build RVs and modular homes in China. Instead, you all should do government software development jobs and reap the excess profit for doing the jobs so much cheaper than mambo bloated firms. I’m sure you and your MIT trained minions could re-write all the code written the past 10 years in just a few months and pocket all the profit.
I myself will continue to do DoD contracting since I know my software development job cannot be outsourced to Bangalore (and since I enjoyed my post-college years and did not care to spend my 20’s working 60 hours a week I lack your early retirement option).
Postscript – in case you did not know, Google is a DoD contractor. Here’s a job where you can have the best of all worlds – google employment and DoD contracting that can’t be outsource to Bangalore
http://www.google.com/support/jobs/bin/answer.py?answer=23545
You are overlooking one of the main reason of time and budget over-runs and failures: sabotage.
And this isn’t just the contractor trying to prolong the project and charge more in time and materials, the client is just as bad. And that is because the people that lead the project on the client side work as much from one project to the next as the contractor does. It is in their interest to drag it out, both to avoid being laid off because there isn’t enough work for all of them, or simply to feel good about being in control and looking good for “fixing” problems they blame on the contractor.
On top of that, more often than not, “the client” is actually some hotshot project manager hired at a daily rate by the real client for the duration of the project. Making it their interest too to drag things out.
The best thing they can hope for is that – even though everything works to spec but their spec was bad and they didn’t listen to us – the project is branded a failure. That way, they can start from scratch and have a whole new project to screw up.
Actually, that is a lie. The best they can hope for is that even when the project is a complete success, one of the vendors of 3rd party technology goes bust or drops the product in favor of another one. (like Vignette dropping their Tcl based solution for a Java one) This way they can claim there is “no support available” anymore and need to once again start from scratch.
“The fundamental tools and debuggers for software have changed but little in 50 years.”
I have to disagree on this, too. I’ve heard from Microsoft engineers, speaking off the record mostly, that PREfix and PREfast are the two main columns propping up Bill Gates’ fortune. I’m not saying these tools are a “silver bullet” and I’m certainly not holding up Longhorn as the model of software development, but you don’t push 75 million LOC out the door using the same old tools and methods.
Continuations for interaction design – and not just web apps. I suppose we will have to wait 20-50 years until the sql of interaction programming comes along…In the meantime I expect to see jobs like ‘program in squeak-earn 500%’ and cursing myself for learning c, perl, and java.
Why don’t those higher iq programmers work out some way of getting that 500% ? surely some of them are as smart as the smart lawyers.
Along the lines of what Dr. Squintum posted, I work at a big, corporate behemoth (they Make Mobile phones). They have what I would consider a ridiculously detailed process, called ‘gates’ that must be checked off the list before the next gate can be started. Apparently all of this is needed to maintain some sort of certification level, without which we’d be less competitive. Who knows. All I know, as a usability/IA/Interaction person, is that it not only makes the development process inefficient, it’s also leaves very little room for innovation (that would take too long and add N days to a schedule that was chiseled into stone before one end user was ever asked anything, let alone “what do you need?”). Also, at least in these cubicle farms, there are many, many project happening simultaneously, and no matter how smart you are, when your time and your brain power are splintered and continually interrupted (“boing- Outlook says you have yet another meeting in ten minutes) it will undermine your best intentions for doing your best and at times doing what’s right.
Would it help if the management style here changed? Maybe a little. Our internal, highly complex process really needs to change, but considering Ed Zander didn’t even know what an iPod was for, I hightly doubt that will happen any time soon.
BTW, urCute 🙂