Business Savvy Software

Your boss walks in and says, “Customer X is going to cancel their contract unless we can deliver xyz functionality. I have a meeting with them in 15 minutes – when can I tell them it will be ready?”

Never, never, never give an answer of the top of your head because it will immediately become gospel. The answer is, give me 15 minutes and then do the following (adapted from Steve McConnell’s “Software Estimation”)

1. Breakdown the project

If you create one estimate for the entire project, then your margin of error is going to be high. If you break the project into the smallest pieces possible in 15 mins, then you will still have a high MOE for each individual estimate, but with a large number of estimates, the MOEs will cancel each other out, giving a more accurate estimate.

Without a detailed design, you may need to break it down into:

1. How many use cases?
2. How many forms?
3. How many web pages?
4. How many features?
5. How many unit tests?
6. How many database tables?
7. How much graphical design?
8. How much user interaction design?
9. How much requirements/design/architecture?
10. How many business functions?
11. How many reports?

Write down a worst case and best case estimate for everything in your breakdown – ie 5 webforms x 1 day per form = 5 days. For worst case, think about if everything went wrong. For best case, think about if you could just sit down un-interruped and build it. Once you have these, think about the most likely case for each estimate – which should be somewhere between best and worst. You can then calculate the expected time using:

expected time = (best case + (4 x most likely case) + worst case) / 6

Add the expected times to give an overall estimate.

2. Understand the accuracy of your estimate

Cocomo II’s “Cone of Accuracy” says that an estimate can only become more accurate by making decisions and removing variables. Therefore, since you can’t define all the requirements, complete the UI design and architecture in 15 minutes, you need to understand the accuracy of giving an estimate based on a concept. If you already have the requirements and design, then you can give a more accurate estimate.

You estimate will only be as accurate as:

Initial Concept - anywhere from 0.25x to 4.0x your estimate
Approved Product Definition - anywhere from from 0.5x to 2.0x your estimate
Requirements Complete - anywhere from from 0.67x to 1.5x your estimate
User Interface Design Complete - anywhere from from 0.80x to 1.25x your estimate
Detailed Design Complete - anywhere from from 0.90x to 1.10x your estimate

For example, if you estimate that the feature will take 4 weeks, based on the concept only, then your accuracy is between 1 and 16 weeks. If you have completed the requirements, then your accuracy is between 2.68 and 6 weeks.

However, telling your boss it will take between 1 and 16 is most likely just to piss him off, so you need to take into account your past history of estimating and delivering projects and you might say 4-6 weeks, 6-8 weeks or 8-12 weeks depending on how accurate your estimates normally are.

3. Differentiate work from time

Maybe its going to take 4 weeks of work and you can assign two developers to it, but if they also have support & maintenance work and are finishing off other work, they may only have 1/3 of their time available to complete the work – so it will take 6 weeks to deliver.

4. Use the right precision

Most people corelate precision with accuracy, therefore if you say, “20.5 days”, they expect this to be accurate to +/- half a day. If you say “20 days” – they expect it to be accurate to +/- a couple of days. If you say “4 weeks” – they expect it to be accurate to +/- one week, etc. Make sure you deliver your estimate using a precision that matches your accuracy from step 1.

5. Understand the risk

So, you come back to your boss and say “Based on the concept – I estimate that it will take 6-8 weeks”. Of course, your boss immediately says – “I need it done in 4 weeks, because that’s when the customer’s next payment is due and I don’t want this delaying their payment”.

We now have an estimate of 6-8 weeks, which is from an expected time of 4 weeks, but based only on the concept – so has a real accuracy of between 1 and 16 weeks and your boss has just given you a business target of 4 weeks. A business target should never be confused with an estimate. Tell your boss that you will specify the requirements/design etc and determine how much you can deliver within 4 weeks – ie phase 1. The rest will have to wait until phase 2 & 3 etc. This way you mitigate the risk of having an estimated delivery time that is much higher than the business goal because the last thing you want to do is make a high-risk promise to a highly-volotile customer.

The larger the gap between the estimate and the business target – the higher the risk. Make your boss aware of this.

Part 2: Estimating a software product.

Xero is looking for developers who want to be involved in the most exciting software development currently happening in New Zealand. Based in the software capital, Wellington, Xero is developing a set of web-based tools to revolutionise business. The foundation of our product is an accounting system, but not as you know it – think powerful forecasting, total cashflow transparency, and complete ease of use. Heck, it’s even fun.

We are a team with a clear vision – we have some of the best UI and graphical designers, architects, developers, testers, domain experts and business thought-leaders in New Zealand and we’re expanding so we can go further, faster. We’re looking for developers who will fit with our can-do, fun culture and who have a passion for building design-led software, using a wide range of technologies.

Applicants with any level of experience are invited to email their CV to craig@xero.com.  International candidates are welcome – we will help with New Zealand work visas or permits.

I had an interesting discussion on hierarchies the other day that left me thinking about perspectives (again). Every time we look at something – we see it from a perspective and it would be wrong to assume that our current perspective is the right one or the only one. This is pretty obvious and the MVC pattern is a common way of allowing different perspectives when viewing data.

One of my top development priorities is extensibility – part of which means architecting applications to allow multiple perspectives. This requires some degree of empathy – to be able to see things from someone else’s perspective (as well as a lot of user research). Allowing multiple perspectives on how data is processed can lead to variations of a rules engine. Allowing multiple perspectives on a workflow can lead to variations of a forms engine, etc.

This is nice when it comes to architecture – because the whole point is to sit down and visualise the end-game, then work backwards, but we also need to setup our data models so that users, who often only see one step at a time from one perspective at a time, will not fall into the trap of mixing up data with perspective – and this means not relying on hierarchies.

For example, hierarchies are the major problem with most file systems – which encourage you to store your files in folders and subfolders based on your current perspective.  They’re also downfall of a lot of website sitemaps which organise pages into sections and sub-sections.  The problem with hierarchies is that as soon as they go more than two deep – you commit yourself to a perspective and you store this perspective with the data. We need to provide users with ways to store the data separately to the perspective – so instead of allowing users to build a hierarchy, another common way would be to allow tags to be added and then use mappings or a simple search to display the data based on the tags.

Following on from my development priorities - I put together the top 10 habits for writing maintainable code for the development team at Calcium. 

This is a work in progress, so I’d be keen to get other people’s feedback and to refine this into a practical list of the ten habits that can make the biggest difference to writing maintainable source code.

Apart from the obvious reasons for writing maintainable code, its especially important when it comes to preparing for investment, a trade sale or a source code sale.  Over the past 2 years, we’ve had the source code of one of our projects sold and had a due diligence team come in to review our processes for an investor.  In both cases, we had to rely on key people in our dev team to provide the knowledge and to be available to maintain the code.  My goal for focusing on writing maintainable code (including using Enterprise Architect) is to ensure that we can hand over our source code – without being personally tied to it and also ensuring that we can demand top dollar for it.

Enterprise Architect (www.sparxsystems.com) is a UML modelling tool that I’ve been using for the past year and is taking third place on my ‘Top Software’ list.

Its a lot more than just a UML modelling tool – its also a full system documentation repository. By using EA, you are able to keep your entire project documentation including analysis, use cases, features, requirements, architecture, design, testing alive within an environment where it can be easily kept up to date and referenced. EA keeps the source code in sync and as you work on projects across multiple modules, you can build sequence diagrams, class diagrams, requirement diagrams etc to document your projects. This documentation all becomes part of the full documentation of your entire system – including XML comments from the source code. What makes EA even better is that it is database driven so multiple team members can work simultaneously on the same diagram.

When it comes to developing software, there are always trade-offs. Do we want to release the product faster and risk more bugs, or slower with less bugs? Do we want to provide customers with the features they want – or just with basic functionality but more robust. This comes down to what importance we place on the following objectives (suggested by Steve McConnell).

• Minimal defects (defects=bugs, not missing or incomplete features)
• Maximum user satisfaction (providing all of the features they want in an easy to use way)
• Minimal response time (ie fixing bugs and getting new features developed faster)
• Good maintainability (low risk of breaking stuff when making changes, the ability to make changes faster and introduce new developers faster)
• Good extendability (making software soft – ie basing core business functionality on a rules engine, or basing the UI on a forms engine)
• High robustness (no crashing, no loosing data, good performance, you trust it)
• High correctness (the lack of missing or incomplete features – getting your requirements right in the first place so you build the right thing)

While some of these go together, most of them are trade-offs and its an interesting exercise to get everyone in your company to rank these from 1 to 7. Because they all trade-off – you can’t put any at equal priority and whatever you put at priority 2 – you are saying should be sacrificed where necessary to achieve priority 1, and priority 3 should be sacrificed where necessary to achieve priority 2, etc.

How you rank these will be specific to the priorities and values of your company – but also to the specific product you are working on.

Currently – not taking into account any specific products, my priorities are in this order:

1. High correctness
2. Good maintainability
3. Good extendability
4. High robustness
5. Maximum user satisfaction
6. Minimal defects
7. Minimal response time

By first focusing on your business and user requirements, architecting for extendability and coding for maintainability – you can give your product a strong base – and then almost forget these aspects and focus on robustness and user satisfaction.