There is a nearly unlimited collection of views about how to write software for money.
From the anarchy of gaming coders sitting in the basement of the incubator on 28th and Pearl Street here in Boulder to the full verification and validation of ballistic missile defense system software, 7 miles up the road.
When I hear about how software should be written, how teams should be organized, how budgeting, planning, testing, deployment, maintenance, transiston to business, transistion to production, sustainment, and the myriad of other activities around software development should be done - the first question is always - what's the domain you're speaking about.
Then - have you tested these ideas outside our personal experience. And finally have you tested these ideas in another domain to see if they carry over? If you're just exploring ideas, no problem. But that limits the credibility of the idea to being just and idea with no actionable outcome, other than a conversation. Those paying for the software you are writing for money, usually don't like paying for you to explore using their cash - unless that effort is actually in the plan.
There are of course fundamental - immutable actually - principles for any project based endeavor. These are the Five Immutable Principles of all project success, shown over and again in the root cause analysis of failed projects.
- Do we know what DONE looks like in some units of measure meaningful to the decision makers?
- Do have any idea on how to arrive at DONE at an expected time so the user can put our efforts to work when they are needed?
- Do we know what resources we need to perform Number 2? These include talent, facilities, and of course money.
- Do we have any idea what's going to go wrong along the way and how we're going to handle it so we can show up on time with the needed value the customer is expecting?
- And finally, how are we going to convince ourselves we are making progress at the rate expected by those paying for our effort?
All five of these principles need answers if we're going to have any hope of success. No matter how often it is repeated, insisted upon, or how clever the message is trying to avoid these principles, they're not going away. They are immutable. They need to be answered on day one and on every day until the project is over.
So if we are writing software for money - internal money, external money, maybe even our own money - ask these questions and see if our answers are credible.
- We don't know what done looks like, so let's get started and find out. This is a good way to spend more money. Write a few sentences about what capabilities will be provided by the software. Use these to test the business value. From those capabilities, requirements can emerge. Don't listen to anyone who suggests software requirements age if not put to use immediately. Think of the requirement of properly interfacing with the IEEE-1553 bus next time you're sitting in seat 23B on a 737 watching it fly through the air. That requirement was set down in 1973.
- Without a plan any path will get us lost. Make a plan. It can be a set of sticky notes on the wall. Or it can be 30,000 lines of an Integrated Master Schedule to fly to Mars and return. Never ever listen to someone who says planning isn't needed, they've probably not been accountable for delivering on-time, on-budget anything.
- How much will this cost? Don't know? It's going to cost more than you think. If those providing you the money aren't interested in how much you're going to spend, when you're going to spend it, cash their check up front, because they're going to run out of money before you're done.
- Risk Management is How Adults Manage Projects - Tim Lister. Behave appropriately.
- Tangible evidence of progress is always measured from the users point of view. In the end measures of effectiveness are the best assessment. The Measures of Performance. Compliance with requirements is weak. We have lots of examples of compliant, but no useable products. When someone says working software is our measure ask what are our units of measure of "working?" Don't confuse effort with results. Show me it does what we planned it to do, on or near the day we planned it to do it.
More in next post about the economics of writing software for money.
