Even though we have been developing software as an industry for the last 50 or so years, it still seems difficult to predict the outcome of a software project. That was obvious to me as I built my software company.
I have more than two and a half decade of experience in both writing software and also managing software projects and teams of developers. I have written open-source software that’s been downloaded more than 234 million times. [Updated (1 Oct 2024): 537 million times+]
How do you get around the problem of coordinating developers and time and resources, and ensure your project will be successful and provide a suitable return on investment?
The first step was realising that there are axioms in software development which seem largely unknown and the failure to know them meant we kept making the same mistakes.
Axioms are statements that are accepted to be true. They serve as a premise or starting point for further reasoning and arguments. The word comes from the Greek axíōma ‘that which is thought worthy or fit’ or ‘that which commends itself as evident.’
From my perspective, axioms are laws that you can’t really break if you want to stay sane and survive in this environment. Knowing them can ensure you adequately plan and set yourself up for success.
Second step was the realisation that software developers are not the builders of software, they are the architects. I wrote another article about this: What does a software developer do?
Properly understanding the role of a developer gave a solid foundation upon which I could begin to codify the axioms of software development. Understanding these will really help you to control development projects:
The axioms are:
- Desired features will ALWAYS exceed available budget
- Communication is king
- Always consider the return
- Design - Validate - Build
- Be ready to go live
- Ownership & Accountability
- Prefer Stability Over Features
- Stick to your knitting
- Test adequately
- Automation builds productivity
- Maintenance is cheap
This article addresses the first axiom, also the most important and I cover the remainder in the following blogs in this multi-blog series.
1. Desired Features will ALWAYS Exceed Available Budget.
Anyone that has worked in software development will have experienced this. It doesn’t matter what your budget is. The features you want will always exceed your budget and quite often the available time you have. If anyone doubts this, then go have a look at what the annual expense is for software developers/development at Facebook, LinkedIn or UBER or any large software company.
It doesn’t matter how big you go or how many features you develop, you will always have more features to build than your budget allows. This is a critical thing to understand. Because if you don’t get this, you will often be implementing the wrong thing.
That means, for a product owner, is you will not get every feature you want in the application.
You see, software attempts to mirror the real world in some manner. For example, an on-line store is an attempt to mirror a physical store. In a physical store, you are always rearranging your stock and displays, putting a new sign up or re-decorating. You’re changing your marketing, your staff and a myriad of other items. It’s a constantly changing scene.
The only things that stay the same in this world are things that are dying. If you are not constantly improving then you are dying. There is no third option. There is no such thing as ‘staying the same’. If you stay the same, the world around you is changing and improving. So, in effect, you are going backwards in relation to the world around you. Improving and changing gradually over time can give the appearance of something staying the same, but it is also improving.
Software will always be in this constant state of change as it mimics the physical world.
I sell software development as a service to clients. I also have three or four software applications which I maintain with my staff and I have full-time developers on those applications. I spend a considerable amount of money to keep them updated and relevant. I just keep finding more features to add and our users keep requesting new features.
So, how do we use this axiom of desired features ALWAYS exceeding available budget?
We use this to focus the project and to keep it on-track. The key thing is making a list of the critical features needed for your application? What is critical to make this a successful project?
I’m not necessarily talking about a minimum viable product here. A minimum viable product for many projects can be a sketch on a piece of paper that you can show to someone and say, ‘Hey, if I built this will you buy it?’ That could be a minimum viable product. A sign-up form could even be a minimum viable product.
Decide on Features
What I am talking about is deciding on the features to develop and deliver with the software to make it a success? Success could be getting more sign-ups. It could be getting the business off the ground. It could be any factor that determines success for the business. But you need to be very critical when setting out the critical feature list. It needs thorough evaluation. For example, client to developer: Client: Okay, so there’s this feature where if I click on this line-item, it should pop up a window and allow me to edit it. Okay, so that’s a feature, I should be able to edit the line-item.
Developer: But do you really need it to pop-up? Yes, or no? Client: Well, no. It would be nice if it popped up. Developer: But is the pop up a critical feature? Client: No, it’s not. Maybe it’s easier if we just click on the line-item, the page changes and I just edit that form and click save and it goes back to the original page. Developer: What we are going to do is make this “click, edit a form and then go back to the original page” so that it works as a feature. And, if there’s more money and more time at the end of the project that we have time for we will turn that into a pop-up form for you. We can easily do that once we have the other critical features developed.
You might consider this is not the best possible design, and it doesn’t feel like Facebook or LinkedIn. (Yes, that’s because Facebook and LinkedIn spend between one and two million dollars a month on software development.)
You might say that example is a bit of an overkill, developing a pop-up only takes about 3-4 hours.
Blowing Out Project Time and Costs
Sure it only takes 3-4 hours to develop a pop-up, but when you add 2-3 hours twenty times you’ve added 3-4 weeks of development to the project.
That’s the sort of thing that derails any attempt to set proper project estimates and stick to them.
In any estimate a developer looks at the problem from a broad view based on earlier projects they have done and come up with some reasonably accurate guesses on how long it will take to implement the given feature set. They will see ‘be able to edit line-item’ and they can work out it will be about half a day’s work.
But then the developer could be met with the following additional needs:
- It turns out that it needs to be a modal, so then it needs to be a pop-up form on the page.
- What if the form is larger than one screen? Now we need a pop-up form that scrolls.
- What if it’s too wide? Well, then it needs to be different widths.
- What if I’m viewing on mobile? Well, now the modal needs to be mobile responsive. So, I’d better fix that.
- Oh, but what if they are viewing in Internet Explorer, not Chrome and it doesn’t necessarily support grids at this time. Now we have to create custom CSS.
And on it goes. Suddenly that “simple” modal project went from taking three hours to three days.
These are the sort of things that you encounter as problems.
The most important aspect of the project manager’s job is to whittle down that critical features list to be as bare bones and simple as possible. You can always add features later. There is no limit to when you can add more features.
But you have got to get the thing launched. You have to get it live and you have to get it earning you money.
So this is one of the things we go over with our clients at the start of a project. And it’s the number one thing we look out for.
Features, Budget, Quality
This is the triangle of features, budget and quality. The more money (or man-hours) you have, the more of each of those you can have. But if you reduce budget, it’s going to also reduce features and/or reduce quality. So these three items are related in every software build.
They work hand in hand. And really, pick any two. That’s how we describe it to a client and how you can describe its relationships.
In Summary
Remember, features will always exceed available budget. Know that and you can set yourself and your team up to win.
This is part of the series on the Axioms of Software Development. If you haven’t read them all - you can see them here.
