BTW, urCute

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.

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.

“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.

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.

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

“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).

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.

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.

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