I can hear you now, screaming “These two things are totally opposite to each other, how can I build a quality product if I don’t do loads of work?”, don’t worry, I’ll give you some information, and you can decide whether or not its possible.
Let’s start with minimising work done, and what that doesn’t mean.
It doesn’t mean:
- Not doing any work
- Not providing any functionality
- Not writing code
It does mean:
- Writing the least amount of code required to fulfil a piece of functionality
- Not spending all of your time designing before you start writing code
These are both controversial items and even they are at odds with each other.
Sometimes we get great ideas, and feel that we must implement them immediately, otherwise it’ll never be done. If you feel this is happening to you, I’d ask you to ask yourself “Why won’t it get done?”. The answer here is probably because it is not important to your users. Have you asked them if they want your idea? If they say yes have you asked them if it is more important than the current priorities?
On the flip side, you might decide to spend all of your time designing your solution, so you know exactly how it will achieve the desired outcome before you have implemented it. You might even spend up to two or three days designing a solution. Inevitably, during the implementation phase of your design, you will come up against something you had not thought about. You may go back to the drawing board, and start your design again, taking into consideration what you have just learnt. This is time consuming, and is of little benefit to the overall design, as what you thought you knew is not relevant. How about, you take a rough, initial, 15 minute diagram, and give it a go. And adapt the design on-the-fly whilst implementing it. You will probably stay roughly akin to your initial 15 minute diagram, because you can adapt to what you have learnt as you implement the design. I also think it is important to go back and refactor, and remove anything that is dubious, or is not needed. Deleting code is satisfying, because it is another headache you will not have in a few months time!
The things I want you to take away from Minimising Work Done are:
- Take risks and try a solution, Learn from it, and adapt as you go.
- Start the solution with a minimal design only. Learn from it, and adapt as you go
- Use TDD/BDD to write just the code you need to fulfil the desired behaviour
You will still feel like you are contributing, but it will feel even better, because you will be delivering exactly what your users are after, and there will be no wasted effort.
Now, building a quality product. Quality is hard, it can take all forms of subjectivity to define quality with regards to the product you’re working on.
So start with asking: “What does quality mean to me?”
If the answer is “A product that does just about everything under the sun, or all these wonderful things I can think of.”, then we need words!
A common understanding is that a quality product is not just what you think is a good idea, it is also what your users or customers think is a good idea. It also means the things they think are a priority to them. For example, they may be able to work without actually ever logging into a system, so by forcing them to do so, you may be detracting from the usability of a product. If your application requires them to set up lots of settings in advance, but every user has the same settings, they may not even use your product at all.
Instead, turn quality into objective measures. Measuring quality is difficult, but here are some examples:
- Number of days the build is green
- Percentage up time
- Code coverage & testing status
- How many features do we deploy in a day?
- What is the turn around time from inception to production?
- How long does my automated pipeline take to deploy to production?
- Is there an accessibility rating for my product?
- How many errors do I log in a day?
- How many known vulnerabilities are there in my product?
- How many have I fixed?
The above are objective, quantifiable measures of quality, associated with a product, so that you know you are building quality in from the start. There are other measures for quality, but they really are subjective. It is still important to gain feedback from your users as to whether or not they like the product, it does what they need, and what they want next, but that forms Customer Satisfaction, rather than quality.
So, back to my original question – “How can I minimise work done, and build a quality product?”.
By creating an initial high level design, learning and adapting, and thinking about quality as a series of objective measures, you really can minimise work done and build quality right from the word go.