Impress your CTO – avoid these boring complaints

Here are some of the most boring complaints I hear.

• No-one knows how it works
• You can’t measure the quality of what I’m doing
• It’s because of all of our technical debt
• We need to re-write this from scratch

They each contain an element of truth but at the same time they manage to completely miss the point. Hence boring.

No-one knows how it works

This really means “I don’t know how it works and nor does the person I usually work closest with”. I once saw a developer spend a huge amount of time trying to recreate, by reading the friendly source, the possible state transitions for a particularly key entity. Because “no-one understood it”. This had two problems:

1. He may have missed something
2. By reverse engineering requirements from the working code, what he ended up describing might have included bugs rather than how the feature was supposed to work.

And in this particular instance I could have pointed the developer to one person still in the business and one person who had left but would still be helpful. Next time you’re tempted to assert “no-one understands these state transitions” just change it to a question: “Is there anyone either on the team here, or who has left but is still friendly, who can help me understand how these state transitions are supposed to work?”

You can’t measure the quality of what I’m doing

This is invariably an attempt to hide something. I once worked with a team who didn’t report their test coverage because the lead developer felt that software is too complicated for a metric as simple as test coverage to be meaningful. We debated the subject and eventually agreed that although 100% coverage is probably not that meaningful, it is worth at least knowing where you are. Where were they when they measured code coverage? About 15%. I was amazed. Here we were debating the costs and benefits of 90% or 100% code coverage and all the time we were staring 15% in the face. I cannot think of anyone who would seriously argue that code coverage of 15% is in any way acceptable. For sure, you can’t measure everything, but the skill of a good developer is in helping finding a useful metric to use. For example on a recent project we agreed on a simple metric that if RubyCritic gives us an  A or a B grade then that’s good, if it’s any worse then we need to know why. It’s not perfect but it’s a lot better than hiding behind “you can’t measure what I’m doing”.

It’s because of all of our technical debt

As an experiment, I once agreed with a team to spend one month just doing technical debt cleanup. The results? Nothing noticeably better or faster for the users, nothing notably better quality as far as the QA people were concerned, no metric to show anything had improved, and I was still getting the same developers 3 months later making the same complaints about technical debt. The reality is that there will always be technical debt of some shape or form. Just like real world debt, some technical debt can be good if it helps you achieve other ends that you couldn’t otherwise achieve. Better developers would have a plan that says, for example, “Technical debt in module X is causing us problems, in order to fix those we will need to do Y”. This is better because it is specific and measurable and, if defined well enough, deliverable.

We need to re-write this from scratch

Stop thinking that. It’s a dreadful idea. Whenever you think of re-writing you are thinking of the 20% of the system that is a PITA to maintain. You’re not thinking of the 80% of the system that you will also need to re-write. I remember one project where a 5-month re-write was still going on 18 months later, still with no end in sight. And another where a re-architected system was being built in parallel but wasn’t able to keep up with the new features being added to the “legacy” platform. In shoert I’ve never seen a complete re-write that people were glad to have done. If you do need to make dramatic changes then you will need to find some way to change very specific parts of the application one by one. It will take a very long time: make sure you do your homework before advocating this.

Impress your CTO – Define your own NFRs

In the last instalment I talked about unspecified requirements. These are the ones that your product owner takes for granted: Of course the system should export to Excel; of course it should authenticate with Facebook; of course the system should load pages blazingly fast irrespective of how much data is thrown at it.

The most common of these unspecified requirements are the Non-Functional Requirements (NFRs). And the most common of these NFRs is “how long should the response time be”. So I find it surprising that response times are very rarely (if ever) mentioned during requirements definition work. Avoiding the topic early in the project is a sure way to have problems later on in the lifecycle.

It’s not uncommon to experience a conversation like this:

Sales: “This software is dreadful, it just took forever to load the dashboard in a crucial demo”
Dev: “Let’s see what’s up… oh yes you created a wizzabanga with 38 different permutations”
Sales: “Well yes of course I did. Then it took forever to load into the dashboard. Your software sucks.”
Dev: “But we didn’t have any NFRs”
Sales: “What’s an NFR”
… some tedious conversation ommitted ….
Dev: “So give me an NFR”
Sales: “OK, I want the page to load up in 200ms even if I’ve got 1000 wizzabangas each with 100 permutations”
Dev: “Hmmm… going to cost you”

etc

It’s meaningless to ask your user base for open-ended NFRs. Clearly they want everything to be really fast and really easy and really secure and ready next week. Much more useful would be for you to set out some reasonable NFRs that you think are deliverable in a reasonable timeframe and, even impose some sensible limits or warnings in the system to ensure those NFRs are supportable. Then at least you have an NFR, even if it’s one that you created.

For example if you think it’s reasonable for the page to load “fast enough” if your wizzabanga have up to 10 permutations then either impose a limit in the UI, or even just a sensible warning, “e.g. we recommend that you have no more than 10 permutations in your wizzabanga. You can add more but please note that you will need to be patient when loading larger wizzabangas.”