Getting real: Book review
I recently came across 37 Signals ‘Getting Real’ book where they go through their approach to building web applications and there have certainly been some good reminders and ideas on the best way to do this.
These are some of my favourite parts:
Often on projects I’ve worked on we’ve taken the approach that bugs get worked on before new stories which makes sense in a way because it means that we are fixing problems quickly and keeping the quality of the application high.
In reality what often happens is that low priority bugs just end up not getting looked at but I like the fact that we can choose to make that an explicit approach rather than just allowing it to happen to us.
Just because you discover a bug in your product, doesn’t mean it’s time to panic. All software has bugs – it’s just a fact of life.
I find it interesting that there might be more value in getting something out the door and then getting feedback on it rather than spending extra time perfecting it up front.
From my experience a lot of times we end up implementing features just because that’s what was agreed in the initial release plan and there is often a reluctance to change that even if a feature isn’t really that useful anymore.
It becomes even more problematic if we get to the stage where it’s not possible to deliver all the features promised in the remaining time so it certainly makes sense to me that in that situation we would look to focus on getting the absolutely essential things in first.
This seems to be a much better idea than just copying the ideas of your competitor which might seem the obvious thing to do if you’re working in the same area.
The problem with that approach of course is that when you do copy you have no actual vision of what you’re doing with your application anyway so you’ll always be playing catch up.
There are a few parts of the book where the authors talk about keeping the application simple and then letting the users play with it:
Keep it small. Keep it simple. Let it happen.
The users can then decide for us where we need to fill in more details:
In particular they suggest that focusing on very specific details about the page layout/colour/wording can be left until later because it will only serve to hinder forward progress if we concentrate on it too early.
“Will my app scale when millions of people start using it?”
Ya know what? Wait until that actually happens.
On several projects that I’ve worked on there often seems to be a desire to focus on performance and scaling an application very early on which seems wasteful when we could be focusing on actually building something that has so many users that we need to scale it later on. I think this advice is spot on.
A common theme throughout the book is that of writing less software to achieve our goals:
That’s where the real gains are made.
Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.
Throw away customer feature requests - if they’re really important then they’ll come back anyway
Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget.
The authors ideas around preferences were particularly interesting to me:
More options require more code. And there’s all the extra testing and designing you need to do too.
I hadn’t appreciated until recently quite how much complexity we can add to an application by allowing users to play around with the display of information on a screen.
It seems like a nice feature to have but it would be interesting to see statistics that could tell us what percentage of users actually that type of thing when it’s not the core idea of the application.
I also quite liked the following and I think it’s something that we need to do more often on teams:
Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn’t work out.
I think a big part of this is getting the mentality that it’s fine to make changes after we’ve ‘finished’ something. Any other approach doesn’t work from my experience.
I find it interesting that they prefer communicating by email because I’ve often found that it’s not the best communication mechanism since it’s really easy to misinterpret what people mean.
Having said that if we can make concepts clearer and the need for a meeting is an indicator that we need to do that then perhaps we can still meet in person and just make the meeting much shorter.
I’ve certainly fallen into this trap a lot but I’ve been trying to follow the outside in approach more strictly recently and so far I’m finding that it reduces the feedback cycle quite substantially which is only a good thing.
For each screen, you need to consider three possible states:
Regular The screen people see when everything’s working ﬁne and your app is ﬂush with data.
Blank The screen people see when using the app for the ﬁrst time, before data is entered.
Error The screen people see when something goes wrong.
I’d never even though of this at all and I’m certainly guilty of only ever considering applications when all the data is filled in so this is certainly something else to consider.
My colleague Chris Read and some others seem to be trying to close this gap with the devops movement which also has a track at QCon London this week.
The idea of working in support to see what an application is like from that perspective is something that more experienced colleagues often recommend although I’ve not done it as yet.
Overall I found this book a really interesting and quick read and although many of the ideas suggested seem like common sense it’s strange that we often don’t do all of them.
The 37 Signals guys also have a new book coming out in the UK tomorrow titled ‘Rework’ which sounds like it could be quite a good read as well.