2080 Software Development
From 2080 Development community.
This article applies to custom software development. We believe that 80% of business challenges require a customised approach. This article will delineate why, and how to do it.
Contents |
The 2080 rule revisited
Historically, the Italian economist Pareto noticed that 80% of Italy's wealth was owned by 20% of the population. While this has a 'rule of thumb' feeling to it, it showed that this distribution has a good shot at explaining a lot of distributions found in different fields. The current most common explanation is that 20% of the effort delivers 80% of the result.
In Software development the rule has become synonym with the issue that in a software development project, the last 20% of the work take up 80% of the time and hence budget. Whilst known among developers, this fact is usually omitted when starting a project and hence creates a lot of frustration in the form of projects going over budget and over time. We will discuss in point 3 how this can actually benefit your project. However, we first want to take a closer look at implications and applications of the 2080 rule.
We have already seen that 80% of development is done in 20% of the final time (if we dare look back at the end of the project), and that the last 20% of finalization drags on to take 4 times as long as the initial build. But what else?
about building custom solutions
The rule applies firstly when making a buy-or-build decision. Off-the-shelf software (be that open source or proprietary) does indeed include - usually - about 80% of the required functionality. It is tempting to say that this makes an unbreakable case for taking an off-the-shelf solution and making it fit your needs. This does however not take into account the 2080 rule. Because we tend to think 80% of functionality is there, we think we are almost done by paying our license. The 2080 rule shows this wrong. The 20 missing percent of functionality will definitely take up 80% of the build time. This is especially true since the 'shelf' product we use was not built with our specific needs in mind, but more likely to fit as many customers as possible as good as possible - but never perfectly. Hence, instead of thinking we can cut 80% of a development budget by using (or buying) an existing solution, we are more likely to cut just 20% - if all building of extras goes smooth as silk.
Then again, we are still ignoring another 2080 rule: that we are most likely to use just 20% of the existing part. I don't want to go into the discussion of needlessly used disk-space, processing power or memory. Whilst true, this is usually not an issue in a time when computers still follow Moore's law. We are talking about these features bothering your users. If you use only 20% of Word's features, this means 80% of menu items are basically there for no reason. It makes for a lot of searching for the features you do use! We are not talking of rebuilding Word - we are talking about small, company-specific tasks like budget management, holiday approval etc. simple basic tasks where every company has its own particularities and hence a huge amount of possibilities need to exist in any shelf application, with only a tiny being used (and as stated above, the most essential one likely missing).
We think that the 2 implications above make a compelling case for custom-built applications in -well- 80% of the cases. When using the 2080 approach, deciding on this is the first step to take in full honesty.
As soon as the decision is made to build a custom application or to use an existing one (the next steps in the 2080 SDM are valid in both cases!) It is essential to make a business case that sticks to the 2080 principle. Do not tell the manager that you only need x budget without thinking of the 2080 rule: you need x budget for a first proof of concept, but you will likely need 5 times that amount for a fully functional system! By acknowledging this, 2080 projects are much more likely to stick to budget and timing than previous agile methods (although by being realistic they tend to estimate the initial budget higher). Now is the time to start using 2080 to your advantage. Being kindred with agile methods, 2080 uses rapid, iterative prototyping for development. Yet, by living with the 2080 rule we can use this to our advantage. We can show the users 80% of what they will get after using only 20% of budget! So, we will insist on building a prototype application that can immediately be tested by the customer. Unlike our agile friends, we see this as a phase and not an iteration. It is a possible (though unlikely) conclusion that we are completely on the wrong track and need to abandon or totally rethink the project after the prototype phase. Luckily, we will only have used 20% of budget at that stage. A huge saving over traditional development methods, where end-users only see that the result doesn't suit their needs after most of the budget has been spent.
Do we need to draw out the process still further? Well, software development in itself is probably just 20% of the work to be done. Re-engineering processes ahead of the implementation, building user involvement and acceptance, making sure the solution puts you ahead and not just in line with your competitors are -well, I guess- probably going to take up 80% of the time, budget and resources. So that's why this is the scope for another article.
The 2080 principles & approach
- Tell it like it is: The project cannot be done in a month for 20% of the budget. However, we can make a working prototype in a month for 20% of the budget. This will be used to make the business case, not as an alternative for executing the project.
- Build the 20: Build a working prototype. This will be the basis for all further development. Make it robust, stable and expandable. Your prototype will define the feasibility of the project. The prototype is a working version of the project that lacks in complex functionality, but that clearly shows how the final program will work.
- Make the business case: Use the prototype to involve users, management and stakeholders to get the full buy-in so you can make the project work. If the prototype does not show the possibilities / results / savings expected, dare to say so and start anew.
- Walk the 100: You don't get the 100% until you build the 100%. Don't settle for half the budget or timing. As a business method, 2080 means deciding after 20, but walking the full 100. The aim is, from the moment you get a go on the prototype, to build the complete project as a working whole. As important as it is to get the project done for the full 100%, it is to get the project finished. Iterative, adaptive development in 2080 doesn't mean continuous development.
How 2080 benefits your business
The 2080 Development Methodology bridges the gap between the business expectations and efficient software development. While the management expects a development project to be a clear project with defined timings and budgets, in practice it more like a reengineering effort. Processes become clear during the project, need rethinking and redesigning, testing and implementation - with a lot of work to get user acceptance. That is the reason most 'bunker-projects' fail, there is no way to have all requirements specified in advance and all users involved on launch day. On the other hand, continuous development projects are not good for business. A project needs an end, and when a project is done you have to move on to the next. Contineous development project keep using management resources that should be shifted elsewhere after the project is complete. Thus, 2080 allows for quick, visible results in the 20 phase, ongoing enduser interaction and adaptive development in the 80 phase and a clear target: to reach 100 and move on.
2080 As a post-Agile development method
When we discuss the 2080 Development methodology, we are often confronted with questions regarding Agile development. We consider 2080 to be post-agile in the sense that it combines the software developers' viewpoint of agile with the business viewpoint of the management. Agile development was a reaction to old-fashioned business models being used for the relatively new concept of software development. The Waterfall method is a good example of this. It is derived from the old planning methods that involve, say, building a factory. Projects were managed trough a thorough analysis, hoping that all requirements are known and stable, and then build to plan. When this method clearly failed, the development community - being used to build small apps for their own problems most of the time - started working on the antithesis in the form of Agile development: small, working programs for specific problems. So why do we consider the 2080 SDM as the synthesis of both?
It is clear 2080 derives a lot of its premises from the principles behind the agile manifesto:
- Like Agile, 2080 aims customer satisfaction trough rapid delivery of working software. 2080 does however still consider these prototypes. The project has a defined beginning and end, being flexible is no excuse for continuing to develop indefinitely
- 2080 is adaptive to changing requirements, but informs the customer of new timings when requirements change. The 'creation' of new needs must be avoided to keep a project contained
- Bi-weekly delivery of versions is preferred
- Business people and developers work together throughout the project at regular, short intervals
- Communication accommodates offshore development
- While working software is a main measure of progress, 2080 never underestimates the value of documentation, integration and alignment with corporate goals
It does however contrast sharply with these propositions
- Unlike the agile manifesto, it is clearly not the aim to continue developing indefinitely. A project has a scope and defined timing and budget
- Maximizing the amount of work not done is limiting in practice. You cannot get 100% of the result with 20% of the work, you get 80% of the result. To get the full 100% you will need to walk all the way.
Use 2080 tools for 2080 development
The 2080 philosophy can be further sustained by using the right tools for the job. Not only is a scripting language like PHP recommended, there are several tools that can further allow you to finish a prototype in a couple of days or weeks.
- Qcodo (http://www.qcodo.com/) is a completely object-oriented framework that takes the best of PHP and provides a truly rapid application development platform. Initial prototypes roll out in minutes instead of hours. Iterations come around in hours instead of days (or even weeks). As projects iterate into more cohesive solutions, the framework allows developers to take prototypes to the next level by providing the capability of bringing the application maturity
- ExtJS (http://www.extjs.com/products/extjs/) is a tool to quickly create Cross-Browser Rich Internet Applications.
