Key considerations for early-stage development
At The Lead Developer UK 2016, Heidi Waterhouse shared her key considerations for early-stage development in what she refers to as the ‘Seven righteous fights’. Watch her talk in full on Vimeo.
As developers we each have elements of a project we prefer to work on. As such, we can become prone to ignoring – or at best procrastinating – the other crucial elements. And in doing so, we end up building up ‘development debt’.
By way of illustration, think about basic pensions savings advice. We’ve all heard about the benefits of compound interest and how saving early is a huge bonus in the long run. But have you ever thought about it in terms of technical debt? The reality is that if you don’t save now then you are going to need to save harder in the future.
It’s the same with early-stage development. There are certain key elements that, if not implemented or fixed at the beginning, will cost you dearly further down the road. Heidi organises these elements into what she calls the ‘seven righteous fights’.
The seven righteous fights
Planning on selling in another country? Then you cannot overestimate the value of hiring a localisation expert for a few days – somebody who will tell you what you need to aim for from the start. Just a few of the things Heidi has learned along the way are:
- Be sure to consider translation at the outset
- Don’t hard code interface elements
- Don’t use words, logos or images (because the ability to translate is tough)
- Consider extended character support (don’t disrespect people by not allowing them to enter their names properly for example)
We don’t know what a hacker looks like. As a consequence, good security is not cheap or easy – but investing in it at the development stage sure beats the alternative of getting it tragically wrong. Leave room for encryption, and create a plan to kill redundant data such as closed user account data from the outset. After all, the more data you keep, the more thread surface you leave vulnerable to attack. Another thing: license and pay for your security – don’t roll your own. And please: don’t use the word ‘secure’ with people unless your software is really secure.
Don’t be so sure that your APIs will remain internal forever. Think longer term and name them well - if they go external it will create a huge headache if they make no sense to the outside.
Secretive build engineers are bad build engineers – you’ll spend forever trying to get information out of them. Documentation should not be a state secret. It should be seen more as subtle self-promotion. People don’t buy software solely based on PowerPoints – you’ll need public documentation that is more useful than Stack Overflow. Plus, good documentation allows you to on-board new developers quickly.
Affordance is the subtle clues that signpost your users on how to use something. When we create software it is too easy to follow best practice without thinking about what a user would do. Take privileges: it’s easy to give yourself all the privileges, but try doing what you need to do with user permissions. If you find it’s a nightmare, change it.
Remember one thing: humans are your users. And they don’t want to use software – they want to edit photos or connect with friends or do whatever your product or service does. So, find real people that represent your users and then observe them using your software. And don’t explain to them how to do it. (What is important is how it works for them and not how it is supposed to work.) By acknowledging that software is a tool and not an end, you will be led towards better development.
Finally, think about how people access the software you’re developing. For example, you can always spot software that’s been developed on giant retina screens… because it looks great until it’s on a small screen. So, have a look at your work on your sister’s phone and your partner’s phone. And remember that not everyone has the same access – poor internet connections are far more common than many of us like to think. And ferocious firewalls on a work computer are pretty commonplace too.
These seven things are worth fighting for at the beginning of each development project. But clearly you can’t do everything at once. So, Heidi suggests you start with a few things:
- Write a coding style guide and follow it
- Hold brown bag lunches with your developers
- Pair programmers to encourage best practice
- Set up accessibility testing
- Cultivate diversity and representation on the team
- And ask questions of everything!
On this final point… like it or hate it but money is the root of all business decisions. So, thinking back to the example of pension advice earlier, ask yourself what the costs of NOT doing something are. Because the longer you leave these development elements, the harder they will become to fix. Leaving them until later is like trying to force chocolate chips into an already-baked cookie.