A recent
article on FastCompany site tells a story about software engineers at NASA that write software for space modules and other such stuff. The story is entertaining and instructive but what I find naive is the idea that engineering approach used for this kind of projects at NASA could (and should!) be transferred to other kind of projects.
First, who writes it?
That's the culture: the on-board shuttle group produces grown-up software, and the way they do it is by being grown-ups. It may not be sexy, it may not be a coding ego- trip -- but it is the future of software.
It's a bit of a stretch, but I mostly agree here. To create a good software you need professionals. Software production is a complex activity and experience is a key. It doesn't really matter whether you look "sexy" or not and whether you have a spouse and kids. Of course, experience takes time and thus experienced programmers tend to be older and as such, may no longer care much about the "cool outfit" but care more about the family.
Next question: "how do they write the right stuff"?
The answer is, it's the process. The group's most important creation is not the perfect software they write -- it's the process they invented that writes the perfect software.
Yeah, I agree on this but I suspect for a different reason than original authors. Here is another quote which clarifies their reasoning:
The most important things the shuttle group does -- carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code -- are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering.
I think they are putting the cart before the horse. They succeed not because of the process
per se but because the process was a good fit and probably was invented to match the kind of projects they are working on. And of course, no process would help if the execution is flawed. Attempting to copy the process to different project may lead to Cargo Cult Engineering, masterfully described by Steve McConnell in his
Professional Software Development book.
Even more important and fundamental point - "expensiveness" of this kind of approach. The hard truth is that process above is not viable for a mainstream world of the software development. For a one, you can't really
fix the requirements. And those who think they can often find themselves out of business. And another one - the process must be cost-effective which means finite resources and trade-offs and compromises.
I do believe we (industry) have a long way toward skillful software development and I'm looking for improvements that advances SWEBOK, but thinking that following NASA processes may give that to us is lame.
Well, this post is probably somewhat lame itself, as I'm not an expert either. ;-)