April 6, 2016

90% of software is shit.

(At least) 90% of software is shit. It’s slow, nigh on unusable, and unstable at best. Let’s change that.

This is a short collection of general advice that most software developers do not adhere to—adhering to it will facilitate a way of thinking about software that should make it slightly harder to build the bad kind.

All of these tips will be very generally applicable. I have steered clear of recommending (or recommending not using) processes, as company politics will often make it hard for develoerps to change these. All of the advice is meant to help developers make a change.

Is it the fault of software developers when software is shit? Rarely. But they can make a difference. Here’s how.

Do the leg work #

You are going to have to start reading. If you think you are magically better than all the people who came before you in the industry you are wrong. Never stop trying to get better, especially by exploring the ideas of those who came before you.

A lot of software development books are short and easy to get through, so you don’t need more than twenty minutes during your commute every day to get something useful from it.

Here are some interesting points you could start at:

All of these are some easily digestible resources that I happen to have come across. There are many more out there, spanning many more subjects than those covered by these recommendations.

YAGNI #

Less is more. Seriously. Don’t build things just to build things: make sure it’s a good idea, make sure you build the thing well instead of rushing on to more features.

One thing at a time.

Better to do a few things well, than a lot of things shittily.

If you don’t know that you need it, you don’t need it.

This is not just about features. It is about frameworks too: do you need React for that? Probably not. You really don’t need jQuery. You should probably write that shit by hand instead of opting for bootstrap.

Need a simple grid? Learn how to do it. It takes 30 seconds to implement. Don’t go for bootstrap because you need one element. Start small.

Use bootstrap as inspiration, sure. It looks great, and is well-implemented. Learn from it!

Yesterday’s Weather #

How are you doing? How did you do in the past week/month? What went well, what didn’t?

Constantly reevaluate your process. Focus on the immediate past, don’t try to remember further back (you will rationalize stuff).

Constantly reevaluate the features you have been developing. Did they work as expected? Are they having the expected impact?

Of course, this only works if you set concrete goals for each thing you do. So do that.

Burn your Gannt charts (or work around them).

Time to breathe #

You don’t make good software by cramming. 40-hour work weeks in front of a screen are a shit idea, not to mention the 60-hour ones.

There may be reasons that taking time to breathe is hard, but I’ll recommend it anyway:

Water Cooler Moments are hotbeds for innovation. Taking breaks from a problem and talking to colleagues means you take breaks from focusing on the problem. Don’t worry: your brain is solving the problem in the background.

Ideas are serendipitous, so make sure you get knowledge from other fields, too. You might make a connection you didn’t expect to make and find a better solution.

Watch TED talks.

Read fiction.

Test usability #

You have no idea if your software is any good if you’re the only person who has ever used it. You thought of the user interface, so you know how to use it. You have no idea if some other user will understand how to interact with it.

Take out a few minutes for a quick usability test. If you don’t have access to (or time to include) actual users you can make do with a colleague.

The important thing is letting them explore the application without telling them what to press, or what different parts of the program do. Let them try and fail, and take that as feedback to the interface.

This doesn’t have to take a long time. Three minutes should give you a lot of useful feedback.

Spread knowledge #

You are probably not working on your software alone. Share what you know with your colleagues: help them avoid the mistakes you know to avoid.

Do a code review, casually discuss some architecture, draw an idea on a piece of paper.

The great thing about spreading knowledge is that something always comes back at you. It is impossible to try to help someone understand how you think, without you also understanding how they think.

Am I missing some obvious point that helped you make better software? Let me know, I will add it.

I write stuff on a pretty regular basis. If enough people sign up to my newsletter, I will start letting you know when I write new stuff.

Kudos