The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links

News

Article Categories

Archives

Post Categories

Software development must deliver on budget - always

Yes, I mean it: we always need to meet the budget (be that time, money or whatever resource).1

This most likely is not your software development reality. So how come I´m demanding something so seemingly unrealistic, even preposterous?

Why?

The reason for the obligation to deliver on budget is simple: trust.

Software development is a social endeavor. It takes not only two to tango, but also at least two to develop and deliver software: a customer and a software developer.

To accomplish something in collaboration with other people requires trust. Trust is the foundation because you cannot do everything yourself. You need to let go of something and trust a collaboration partner. That´s the very reason for collaboration in the first place. If you were able to do something yourself, why get someone else on board?

So if there is a need for cooperation, then there is a need for trust. Even more so if the relationship between the cooperating parties is highly asymmetric: If you could do something yourself but delegate it to somebody else, you can at least check their work for quality. Less trust is needed.

But if you don´t have a clue how to accomplish something yourself, you can´t help but delegate execution and on top of that you´re unable to check every detail of how the result is produced. You´re pretty much limited to checks on the surface. So you need much more trust in this situation.

Software development mostly is a highly asymmetric endeavor. Customers don´t understand much of it, so they need to trust software developers.

How is trust created? Trust grows through reliability and steadiness. It´s delivering on promises - and even going beyond that. If your cooperation partner does what she promised, she´s reliable. If she does that again and again... you learn to trust her.

And if someone presents you with value you had not even expected... well, that´s even better.

Gifts build trust, keeping promises builds trust.

Delivering below budget is like a gift. Delivering on budget is keeping a promise.

That simple.

What´s wrong?

But why is it so common project reality to not deliver on budget? There is something fundamentally wrong with how the industry (or its customers) interprets the term "promise", I guess.

Promises are a form of contract. A contract requires all parties to freely agree on it, which requires all parties to understand the contractual clauses (in the same way) and their implications and ramifications. And a contract requires all parties to be able to live up to it.

Contracts are the foundation of civilization. The Romans recognized that and coined the term: pacta sunt servanda.

So what goes wrong in our industry with promises?

  1. Software development often is not free to enter a contract. Management states "You deliver such scope on such budget!" - and thinks a contract exists. But it does not. If a party got coerced then it´s not actually part of the contract.
  2. Software development often does not fully understand what´s in the contract, what it implies. Some parts of the contract are clear (mostly the budget), some are not clear, fuzzy, or outright not understandable (mostly the requirements). How can software development then honor the contract?
  3. Software development regularly overestimates its capabilities to deliver on what it perceives to be in the contract. It lacks experience, it neglects dependencies etc. Even though software development freely enters a contract or even defines the budget, it is unable to deliver on it.

No small wonder, so many contracts - large and small - are not honored. Promises are broken. Trust is not build or erodes. Overall quality drops to save at least a few contractual goals. Conflicts and pressure ensue.

How?

The only remedy to this recurring downward spiral, to this pattern is: Always deliver on budget. Always live up to what you promised.

But how?

I think, it´s very simple - which does mean it´s easy ;-)

Only make promises you can keep.

Ask yourself: Am I willing to bet 1000€ I will be able to keep this promise? If not, well, then you´re not in a position to make a promise. You doubt your own reliability.

This simple and obvious rule of course has a couple of implications:

  1. Spot and withstand any coercion. Do not enter any contract you have the faintest doubt whether you can deliver on - just because someone says so.
  2. Be humble with regard to your capabilities. Don´t overestimate what you know or are able to do.
  3. Be realistic in terms of control over your environment and your time. I strongly believe you cannot control more than maybe 1 or 2 days of your time. So you can´t promise anything beyond that.

So what can you promise? Stuff you´ve done already many times; that´s then called reproduction. You can only make promises on what you have considerable experience with and thus can deliver in "reproductive mode".

If you have experience with cooking Chicken Vindaloo you make a promise to deliver in maybe 60 minutes. But how far goes your experience in software development? Even if you´ve been doing it for 25 years your ability to reproduce is limited. This is not just because of ever changing technology, but because of ever changing customer requirements. They are hardly ever the same. As is your software.

Software is like a river: you can´t enter a river twice. Which means, it´s not the same river the next time you step into it. Something has changed, so have you.

Software development is hardly ever in reproduction mode. Mostly it´s a creative undertaking. Stuff needs to be analyzed, researched. Stuff needs to be engineered, invented.

So what can you promise to deliver on budget?

You can only promise your diligence. You can promise to work hard, to focus. But you cannot promise the implementation of a certain scope (functionality, quality) in a particular timeframe (budget). At least not beyond very small increments.

So here´s the bottom line:

  • Promise concrete results only in matters of reproduction.2
  • Since the circumstances for reproduction are rare, be conservative. Even if you are able to reproduce a result, it becomes difficult beyond 1 or 2 days - because you hardly have control over your time.
  • Without the ability to reproduce results promise only one thing: focus. Focus on a contractual topic regularly until the contract is fulfilled. Be persistent, be relentless - but don´t expect to know in advance when you´ll be done. Which means, be honest about this; don´t let yourself be lured into promises you can´t keep.

We can´t avoid to make promises. Promises are the foundation of collaboration. So we must stick to promises we actually can keep. Be extra careful what you promise. With regard to coding the time budget you agree on should be very, very short. And once you´re beyond reproduction mode, only promise diligence.

Who wants to work with unreliable people? Nobody. So we need to strive to become more reliable, more trustworthy. Working with software development should become a pleasure.


  1. An overrun of maybe 5% might be ok to classify a result as “within budget”.

  2. Yeah, I know what you´re thinking right know ;-) But there is more than that kind of reproduction…

Print | posted on Monday, October 27, 2014 11:27 PM | Filed Under [ Spinning ]

Feedback

Gravatar

# re: Software development must deliver on budget - always

Sounds to me like your solution is making no promises at all rather than ones you can keep. I agree that it's foolish to promise things that you don't know how to deliver, but if a customer asks if you can build e.g. a system to help him organize his club's trainspottingschedules and records of spotted trains (or whatever), I doubt he will like the answer "I can give you the train schedule of all train types nicely printed on a webpage." I'd think a minimum requirement by any customer fairly early in a project is to get an estimate on how much time is needed for the project and what the costs are etc. The problem seems to me be more that too often the estimate becomes the contract, but as long as were thinking projectwide on these things, i.e. delivering the entire product, we will always have the same problem as will any other business who deals with projects from start to finish, just look at the budget issues involved in building anything but the smallest house, or even renovating a kitchen, how often are they on budget?

Say you take an approach instead where you say "I can promise to build this feature in two weeks." Then you've made other promises, even if they are not explicit in the contract. You make a promise that the feature is "done" no bugs etc. You make a promise that it's easy to integrate with other parts that others build because how are they otherwise supposed to get any value from it. You make a promise that the code has a certain quality, all the refactorings etc need to be done within budget etc. A whole different set of unknown variables.

And I wonder if most customers would want that. I'm sure they would accept testing prototypes and things like that to refine the requirements, but to constantly have to manage the project may be more than the customer wants and that's what is done if you don't make any committment longer than a few days, you push the worrying of schedules, budgets etc over to the customer, (which is probably where you want it but certainly not where the customer wants it.) The customer is already committing to the project and probably expects you to do so as well.

I think the problem lies partly in how we communicate things, maybe we're not clear enough about our calculations being estimates, maybe we're not clear enough about how feasible some of the customer's requirements are, because I don't think it's an option to tell a customer that "I'll do it, but I can only promise to deliver this little bit here. That's all I know how to do and how much time it'll take."

But as I hinted earlier, I don't think that faulty estimations are a problem of the software industry alone. It is in the nature of prediction that they often go wrong even with good data or as someone famously put it: "Prediction is very difficult, especially if it's about the future." (Niels Bohr)

I would be interested to read though if you are doing this in practice and how you've managed to set it up with the customers etc. How you've overcome the issues I mentioned or if they were issues in the first place.
11/15/2014 9:20 AM | Aimo
Gravatar

# re: Software development must deliver on budget - always

I don't really want to get into the estimation discussion here. We seem to have fundamentally different view points there. Just because a customer wants sth does not mean I'm able to provide it or even willing to try. Like with a pony which little girls want for christmas ;-)

What I wanted to underline in this article is: Promise only what you can keep. Period.

And be very, very sensitive to deviations from your promises. For that purpose, for example, I've taken up the habit to donate 5€ to a charity for each promise broken. That might be "not showing up on time for an appointment" or "not delivering on time" etc.

If you like, promise your customer "I deliver this and that for this budget until this date" with "this date" being some 6 months ahead. That´s fine with me - as long as you keep your promise. 100%! Always!

But if you cannot do that... then you´re unreliabel, then your customers will lose trust. It´s that simple.

I want to be trusted. 100%! (Yes, I know, as humans we fail. But that should be the exception. Otherwise there is a systematic problem which needs to be corrected. I count "50% over budget in 70% of projects" as a systematic problem.)

So just be conscious what you promise. Be sure to keep your promises. And realize why you make promises. You'll realize it's very often out of fear. (At least in a business environment.) It's not because you really want to promise anything, but you feel urged. And you probably do not feel 100% comfortable.

Well, at least I don't like to work in such kind of environments anymore.

For example that's why I don't sign any contracts. No NDA, no consulting contract. They undermine the development of trust, they tend to lead to sloppy communication.

It's like with bicycle helmets: Wherever they have become mandatory, the number of accidents has risen. (http://bicyclesafe.com/helmets.html)

Not signing any contracts sometimes is a problem for prospective customers. Sometimes they give up the requirement and all's well. Sometims they don't and I won't work with them. That's fine with me.

Or, for example, I don't make any promises on dates for trainings etc. more than 8 weeks ahead. For some companies that causes a problem; they would like more long term planning. Well, too bad for them. I won't do it. Why? Because that's decreasing flexibility on all sides. I want flexibility. They think they don't need it - but in the end, many of their problems stem from inflexibility. Especially when you look at software architecture.

So what this boils down to is: courage. Are you willing to stand up for what is right?
11/15/2014 9:59 AM | Ralf Westphal
Post A Comment
Title:
Name:
Email:
Comment:
Verification:
 

Powered by: