· software-development books book-review

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:

  • Ship it!

    If there are minor bugs, ship it as soon you have the core scenarios nailed and ship the bug fixes to web gradually after that. The faster you get the user feedback the better.

    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.

    Prioritize your bugs (and even ignore some of them) 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.

  • Fix Time and Budget, Flex Scope

    You have to figure out what’s really important. What’s going to make it into this initial release? This forces a constraint on you which will push you to make tough decisions instead of hemming and hawing.

    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.

  • Choose any enemy

    Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.

    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.

  • Don’t overcomplicate the application 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:

    The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence. Keep it small. Keep it simple. Let it happen.

    Andrew Hunt, The Pragmatic Programmers The users can then decide for us where we need to fill in more details:

    Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing. You’ll know which potholes to pave over because you’ll keep hitting them. That’s when you need to pay attention, not sooner.

    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.

  • Scaling an application

    You don’t have a scaling problem yet “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.

  • Write less software A common theme throughout the book is that of writing less software to achieve our goals:

    The best designers and the best programmers...are the ones that can determine what just doesn’t matter. 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.

    Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features. 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:

    Preferences are also evil because they create more software. 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:

    Encourage programmers to make counteroffers.You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.

  • Decisions are temporary so make the call and move on

    So don’t do the “paralysis through analysis” thing. That only slows progress and saps morale. 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.

  • Reduce meetings

    Meetings usually arise when a concept isn’t clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire.

    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.

  • Design the interface before you start programming

    Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.

    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.

  • Design for regular, blank, and error states

    For each screen, you need to consider three possible states: Regular The screen people see when everything’s working fine and your app is flush with data. Blank The screen people see when using the app for the first 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.

  • Tear down the walls between support and development

    In the restaurant business, there’s a world of difference between those working in the kitchen and those out front who deal with customers. It’s important for both sides to understand and empathize with the other. That’s why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it’s actually like on the front lines.

    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.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket