How long will this feature take?

Be clear on someone’s definition of done when trying to communicate what it will take to build a feature.

Planning software development timescales is hard. As an industry we have moved away from the detailed Gantt charts and their illusion of total clarity and control. Basecamp have recently been talking about the joys of using Hill Charts to better communicate project statuses. The folk at ProdPad have been championing, for a long time, the idea of a flexible, transparent roadmap instead of committing to timelines.

That’s all well and good if you are preaching to the choir. But if you are working in a startup and the CEO needs to make a build or buy decision for a piece of software, you need to make sure that you have some way of weighing up the likely costs and efforts of any new feature you commit to build. It’s not good enough to just prioritise requests and drop them in the backlog.

The excellent Programmer Time Translation Table is a surprisingly accurate way of interpreting developer time estimates. My own rule of thumb is similar to Anders’ project manager. I usually triple anything a developer tells me because you build everything at least 3 times: once based on the developer’s interpretation of the requirements; once to convert that into what the product owner wanted; and once into what the end users will use. But even these approaches only look at things from the developer’s point of view, based on a developer’s “definition of done”. The overall puzzle can be much bigger than that.

For example, the startup CEO who is trying to figure out if we should invest in Feature X probably has a much longer range “definition of done” than “when can we release a beta version”. For example: “When will this make an impact on my revenues” or “when will this improve my user churn rates”. Part of the CTO job is to help make that decision from the business point of view in addition to what seems to be interesting from a tech angle.

For example, consider these two answers to the same question “When will the feature be done?”.

1. The dev team is working on it in the current iteration, assuming testing goes well it will be released in 2 weeks.
2. The current set of requirements is currently on target to release in 2 weeks. We will then need to do some monitoring over the next month or two so that we can iron out any issues that we spot in production and build any high priority enhancements that the users need. After that we will need to keep working on enhancements, customer feedback and scalability/security improvements so probably should expect to dedicate X effort on an ongoing basis over the next year.

Two examples from my experience:

A B2B system used primarily by internal staff. It took us about 6 weeks to release the first version from initial brainstorming on it. Then it took about another two months to get the first person to use it live. Within 2 years it was contributing 20% of our revenues, and people couldn’t live without it.

An end user feature that we felt would differentiate us from the competition. This was pretty technically involved so the backend work kept someone busy for a couple months. After some user testing we realised that the UI was going to need some imaginative work to get right. Eventually it got released. Two months after release the take-up was pretty unimpressive. But 5 years later that feature was fully embedded and it seems that everyone is using it.

What is the right “definition of done” for both of these projects? Depends on who is asking. It’s as well to be clear on what definition they are using before you answer. The right answer might be in the range of months or years, not hours or weeks.

Impress Your CTO (2)

People expect software to “just work”. You can guarantee that it won’t
“just work” when someone decides to throw more data at than you expected. So my 2nd tip is:

Enforce Sane Limits

From a developer point of view it makes sense to think in terms of 1 to Many or Many to 1. Why put in extra work to enforce some limitation when you can have unlimited flexibility for free?

Because the real world doesn’t work that way and it’s more important to model the real world than it is to create infinite flexibility. Some good reasons:

1. Usability
2. Performance
3. Commercial reasons

Usability

The more “many’s” in your one to many, the more UI real estate you need to think about. Pagination, sorting, searching, exporting lists to Excel. Maybe favouriting so that people can shortlist the results because they can’t make sense of the whole list. Nothing here is super-complicated to code, but given that the scarce resource in most tech operations is developer time, as a great developer you will be ensuring that you are spending your valuable time on the most value-add activities.

Performance

Be honest. You aren’t about to write comprehensive automated performance tests. If you allow people to add unlimited items then eventually someone will do so and, probably sooner than you expect, you will experience serious performance issues. Which then means that you need to be spending valuable developer time addressing those performance issues because by the time you have enough traction to have performance issues you aren’t going to be able to withdraw the poorly performing feature [*].

Commercial Reasons

Maybe a surprise to see this as a reason but it may be the one you would do best to remember. The simple point here is that if the standard version of your product allows the user to add up to 15 items to a Thingamy then not only do you lower the risk of performance issues etc but you have a built-in mechanism that your product managers can use to upsell your customers to the next subscription level: “You want to handle more than 15 items? Let me put you through to our Enterprise Sales team”. If there is demand for the feature and customers will pay for it then fantastic – it will be a great feature to spend some real effort and attention to and give it a stunning user experience that performs really well.

Conclusion

I’m not saying to do anything complicated in your database. Leave the database handling a 1 to Many relationship. Just put check somewhere in your business logic. Next time you are discussing a feature with your product owner and you are thinking about the many side of the object model, just ask the question: “Would 5 be enough?”

[*] This is a case of “do as I say, not as I do” here. In my own side project which allows a user to merge and stitch together data from different Excel files I didn’t impose any limits. I asked some friends and family to test it and the second thing my brother did was try to crash it. It worked. So now I’ve implemented some limit checking.

Impress Your CTO (1)

There are plenty of developers who will happily build the functionality described in a set of requirements.

That is fine as far as it goes. We need requirements and we need to deliver working software to satisfy requirements. But it takes a LOT more than just this to build decent software products. Not only are there a myriad different ways to satisfy a set of requirements, but even more exciting, in today’s agile (small a) world developers have a great opportunity to co-create products with their product owners.  And in the process to become great developers, not just good developers.

So I want to share some personal views on what you should be thinking of to become a great developer. I’m taking for granted that you know your framework, you know how to use Stack Overflow and that you write good unit tests. I’m going to be talking about the other stuff. The stuff that, in my view, distinguishes great developers from, well, just developers. The stuff that, when I see it in my team, helps me sleep more soundly, knowing that the codebase is in good hands.

Here’s the first one.

Learn your database

Your framework is great. It has a lot of really cool abstractions so you can program away without having to (amongst others) handle all the tedious details of writing SQL [1].

Time for a story.

A product owner was launching a new product and wanted to give the impression that it had been around for a long while. A reasonable request, I mean, who wants to know they are being billed with Invoice #1. The solution was to use a higher number. So the first invoice would be #225678 rather than 1, for example.

This is trivial to do with any RDBMS I’ve seen: you just set the auto-increment to the appropriate number, rather than start counting from 1.

Not in this case. The developer didn’t want to get involved in proprietary database commands. He decided to use a parameter, let’s call it INVOICE_OFFSET, to adjust what someone would see on the UI. Sounds simple enough – set INVOICE_OFFSET to 225677 and every time you show an invoice number on the UI or in an email add INVOICE_OFFSET to the database id. Likewise, subtract before you do any CRUD operations on the database.

Can you see where this is going?

It was fine while there was only one developer involved in the product. It soon turned into a bit of a mess when new developers came on board and weren’t expecting this INVOICE_OFFSET idea. For example in a REST situation, would you use the database ID in the URL? Or use the ID that the user would recognise? And then when you were interpreting the ID in the URL, is it a database ID or an adjusted ID?

True story [2].

I fully accept that writing SQL by hand is horrible and so I am very grateful for ORMs for abstracting that away. But too many developers have gone too far the other way and treat the database as a black box. Or go as far as learning about indexes.

Databases are pretty awesome pieces of software, see what else they can do to help you build better applications.

 

[1] Hell, you could even write an application that you can then easily port from one database to another should you want to. Though if there ever was a case of YAGNI, having an app that you can port between databases should be a top contender.
[2] To be fair, I don’t think there was ever a production issue where one person could inadvertently see someone else’s invoices, but it was certainly a PITA during QA time.