Yesterday I posted a fun list of possible Latin mottos for the fledgling ALT.NET “movement” over on the Yahoo! group mailing list – one of them, Aut disce aut discede (either learn or leave) was picked up by fellow ALT.NETter Scott Reynolds and served to inspire his post of the same name. In it, he makes an eloquent if heavy-handed case for either being part of the solution or part of the problem when it comes to improving software development:
This is the most honest statement about software developers (and people in general) that I can make: If you aren't willing to learn, you are obsolete and utterly useless.
New and unknown things trigger our fight or flight response just the same as if a bear came crashing through the woods at us. What will differentiate you from the next guy is whether you choose to adapt, improve, and grow with new challenges or put your head in the sand.
I can’t say I really disagree with this – for too long, our industry has been getting by on its good looks, so to speak, and we’re now well-mired in our own technical debt because we’ve become complacent about continually improving our game. Worse, we’re failing at preparing the next generation of developers for turning this situation around.
However, Scott and I begin to part company when it comes to the motivations for remedying this debt:
A lot of lashback for alt.net right now is coming from a position of fear. A position of not wishing to come out of one's comfort zone. This is the antithesis of what we should be about. We should be out there pushing the envelope and making ourselves, our peers, our companies, our products, and our world better. Chad touched on this in his post about professional responsibility. I left a comment that I thought I would share to a greater audience. It's a quote that Scott Bellware twittered one day a couple of weeks ago:
"Society runs on software. Programming is a social responsibility".
While I’m in total agreement about pushing the envelope, I disagree entirely that “programming is a social responsibility”. While a convenient metaphor, society does not run on software – it utilizes software. Therefore (and with all due respect to Messrs. Bellware & Reynolds), programming carries a professional not social responsibility.
Despite what Trinity is trying to tell you about following the white rabbit, society isn’t a computer construct or even a remote analog. It’s about people and their interactions, shared belief systems, goals, aspirations, security, life, liberty, the pursuit of happiness, etc. While software does play an important role in our daily lives, and can affect such things, it is a tool and not embedded firmware for people. Modern society’s “software” is far older and has undergone much more rigorous refinement (and is still imperfect): It encompasses fundamentals such as a constitution, the Rule of Law, right of habeas corpus, systems of governance, democratic elections, and so on. Add a dash of free will and you have a party.
By way of contrast, software development is a skill and is thus practiced in either a professionally responsible or irresponsible manner. This isn’t a thinly-veiled argument for small-tent elitism – all it takes to be professional is the desire to continually improve oneself through learning best practices and trying to implement them.
For over three decades, our industry has practised irresponsible software development because of flawed practices that were co-opted without taking the time to understand their source. Case in point: Waterfall/BDUF – the “ground zero” from which all manner of recognized worst practices were spawned (and ironically, all best practices in response). As a result, we’ve been left with, as Robert N. Charette notes in his 2005 IEEE Spectrum article, Why Software Fails, a legacy of epic, yet preventable software failures estimated in the tens of billions of dollars:
Worldwide, it's hard to say how many software projects fail or how much money is wasted as a result. If you define failure as the total abandonment of a project before or shortly after it is delivered, and if you accept a conservative failure rate of 5 percent, then billions of dollars are wasted each year on bad software.
For example, in 2004, the U.S. government spent $60 billion on software (not counting the embedded software in weapons systems); a 5 percent failure rate means $3 billion was probably wasted. However, after several decades as an IT consultant, I am convinced that the failure rate is 15 to 20 percent for projects that have budgets of $10 million or more. Looking at the total investment in new software projects—both government and corporate—over the last five years, I estimate that project failures have likely cost the U.S. economy at least $25 billion and maybe as much as $75 billion.
Charette attributes the industry’s high failure rate to a dozen key factors:
- Unrealistic or unarticulated project goals
- Inaccurate estimates of needed resources
- Badly defined system requirements
- Poor reporting of the project's status
- Unmanaged risks
- Poor communication among customers, developers, and users
- Use of immature technology
- Inability to handle the project's complexity
- Sloppy development practices
- Poor project management
- Stakeholder politics
- Commercial pressures
All of these should be familiar to anyone who identifies with the core ALT.NET values – they are our raison d’etre. They are what we continually strive to improve.
So what does this have to do with me, John/Jane Q. Developer?
Everything. As the saying goes, “the buck stops here”. You are the “pointy end” of the stick – irrespective of whether you’re coding the control systems for the space shuttle, imaging analysis for medical diagnostic equipment or a simple ASP.NET web app that renders a report – regard your work as mission critical and develop accordingly.
As a software developer, your professional responsibility (and thus imperative) is to challenge the conditions of IT project failure such as those that Charette identified by making incremental changes in your development habits and skills, and putting them into practice, and thereby influence change in your colleagues. In sum, to do as Ken Schwaber suggested when he was speaking in Vienna about what it takes to move toward agile software delivery: "Don't procrastinate; do something - no matter how small."