How iterative development can save you money.Tue, 1 Oct.
If you haven’t been involved in a software project before, you might be wondering: “What if I hire someone to do this work, and then it’s not successful?“, or “What if I don’t like it?”. Or, maybe you have been involved in a software project before, and those exact questions have come up.
I believe that the key to creating great software is to focus on the primary goals, rather than on features/components (which are the means to those goals).
The computer code that’s created for any project is really the product of a larger functional system. We need to consider the machine; the process by which the code will be created. Whatever process we use needs to reflect our focus on the goals, and consider features as a means to an end.
I’d like to tell you about the development process that we recommend at Litiks, and why I think it’s the right approach for developing web-based applications. We’ll start with a couple of key concepts that I’ve learned as a software developer.
Key Concept #1 - Success will involve change.
There’s one very important thing to understand about developing software that actually works:
There is never just one version.
Your final product will be different than your initial vision. You should plan on it. In fact, you should hope for it. That’s because (in my experience) a successful project is one that reacts to its surroundings. It adjusts its tune to harmonize with the tools, workflows, and needs of its users. Your initial idea might be missing features that your final product will need. Or you might need to simplify a component so that it’s more usable. Yes, it’s important to plan and research before starting development, but if you think your product will be perfect at version 1, you’re fooling yourself. Plan for change.
Key Concept #2 - Changes should be based on testing.
Professional experience and knowledge will help your project to be effective, but it won’t get you all the way there. Even small changes to content, layout, and visuals can have a substantial impact on the effectiveness of your project. By testing different versions, and by analysing usage, we can identify which components are helping, and which are hindering the success of your project. It takes time, and conscious effort to test a project well, but the insight and improvements gained from testing can have a significant impact on your project’s success.
Key Concept #3 - The 80-20 rule of development.
The 80-20 rule seems to apply to almost everything in business. In the realm of software development, it been my experience that 80% of the core development work is completed in 20% of the development time. That is to say; It doesn’t take long to get a feature or component most-of-the-way to completion. The remainder of the development time is spent fine-tuning the appearance, speed, and robustness of the component so that it behaves optimally.
So, we’ve established that developing a successful project will involve changes and testing over time. Naturally, this can make planning and budgeting for a project difficult, since it can be a challenge to know how long a project might take, and how many changes might be necessary.
It’s not surprising then, that many clients decide to save money by limiting the number of changes they’ll make to a project. They’ll often have a mentality of “I know what I need. We’ll make it once, then maybe a couple small adjustments and presto.”
Taking this approach will result in a project that’s exactly what you asked for, but (in my experience) you’ll be disappointed in the project’s level of success.
Alternatively, you can save money by taking advantage of the 80-20 rule. By testing each feature when it’s only 80% complete (by testing it before spending time on visuals, performance, and reliability); we can drastically reduce our development time. This means testing your product with a number of users while it’s unattractive, slow and buggy. Naturally, I understand that you don’t want your final product to be unattractive, slow, or buggy, but by setting our initial focus on feature testing and evaluation, we’re able to make changes and test features much more quickly.
Let’s imagine for a moment that in order for your project to be successful, it will need 6 ‘magic features’. These are the 6 components that will contribute significantly to your project’s success. Let’s also imagine that right now, you have 8 features in mind, but only 4 of them are actually part of the ‘magic 6’.
If we take approach #1; Let’s assume we spend 5 days developing each feature, making sure each component works perfectly, and that it looks and performs great. We’ll spend 40 days developing, and we won’t have success yet. By doing some testing we identify the 4 magic features that we have so far, and we know that there’s something missing. We come up with 4 new feature ideas, and spend the same amount of meticulous energy adding them to the project. After some more testing we identify that only one of the new features is ‘magic’. At this point we’ve spent 60 days on development, and we’ve only got 5 of the 6 ‘magic features’.
If we take approach #2; We’ll still develop and test the initial 8 features, but we’ll do just enough work to make each feature functional (avoiding the 20% portion of ‘tweaks and adjustments’). Following the 80-20 rule, it will take 1 day to develop each feature to it’s 80% mark. We spend 8 days developing, and then test to identify that 4 of our features our ‘magic’. Now, we come up with 4 new feature ideas, and spend 4 more days developing them. Testing identifies that we’re up to 5 ‘magic features’. We can now develop 4 more feature ideas, and after a total of 16 days, we’ve identified all 6 of our magic features. Now, we spend 4 more days on each ‘magic feature’ ensuring that they look and perform perfectly, and after 40 days of development, we’ve got our 6 magic features fully developed.
You have big dreams for your project. I get that. I know the feeling. But it’s important to remember that the success you’re hoping for may require a different approach or featureset than you’re envisioning. You vision might be missing components that will be necessary for success, and your vision might include components that aren’t really necessary. By taking an iterative approach - by starting with basic components and progressively testing and improving your product - you can minimize the amount of ‘wasted’ energy you spend on features that don’t contribute to its success. And, in doing so, you will save yourself a lot of money.
Thoughts? Comments? I’d love to hear your feedback!
Send me an email and I’d be happy to talk with you.