Getting Real - Agile Software Development

Yesterday I read an interesting book, written by the guys behind 37Signals, it's called "Getting Real". 37Signals is a Software Company that was founded in 1999 by Jason Fried and others, and David Heinemeier Hansson who joined the company in 2003 is the one behind the famous web-development platform, Ruby on Rails, which he created as a result of his work on Basecamp, one of 37Signals applications.

So back to the book, which you can read online by the way, is their trial to summarize how one can create software quickly by dealing with the actual problems he is trying to solve and staying agile and less complex. Or as they put it here.

Getting real is less. Less mass, less software, less features, less paperwork, less of everything that's not essential (and most of what you think is essential actually isn't).

I advise you to read it, however let me put here the most import point I liked the most.

As you have seen, the main idea of the book is to "Build Less", where "Less is More" or as Seth Godin put it in his - yet another interesting book, "Small Is the New Big". And you can do this by sticking to the following:

• Half the features is better than half-backed features.
• Ask yourself what is the main problem you want to solve and focus on it. For example, if it's a blogging system that you are creating, then focus on blog publishing part and let the tagging and commenting modules come next.
• Don't compete with your competitors on features, this is an endless war. Beat them with your simplicity and your focus on the needs of your core customers and not the needs of everyone. 
• Feel free to say No to new features requests. If you get a request for adding a new feature, ignore it and let it go. If it comes back to you, its yours to implement. If it doesn't, then it was never meant to be implemented.
• Each time you say yes to adding new features you are adding complexity to your product.
• Settings and Preferences add complexity to your project, and puzzle the uses. Feel free to take decisions for your users.For example, imagine you are designing and on-line shop, why your user go somewhere and set the number of results he gets in a page when searching for something? Why not stop for a moment and think, ain't 10 results too few and will bother the users with pressing next, next. Also 100 results might be too much and confuse the users and might not be suitable for those with slow internet connection. So guess what? You find 25 results is the most comfortable option for you as a user, then why not hard-code it. Well, may be later on, your users might not like this, so then you can think about it, but not now.  
• Start with the core functionality of your software, then move to the less important features.
• Fine tunings like alight this to left, move that two pixels to the left, etc. Those are stuff to be ignored and focus on making things work, and "iterative improvement" is your friend later on.
• If it's not a problem that you are going to face now, then ignore it for now.
• Scale later, don't bother yourself with scalability too early, most probably you will find out how to scale when scalability is needed.
• Skip meetings as much as you can. Most of the time meetings are waste of time, so do your best to collaborate via short and to the point mails, or even tweets.

 Your development work-flow:

• Brainstorm => Sketch => Interface => Code

You sure do the first two steps, you brainstorm then sketch your idea, design, database tables, etc. But being a coder myself, I always start with code then add the HTML to it later on. But let me quote the book to make it clear why the prefer doing the interface first:

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. Design is relatively light. A paper sketch is cheap and easy to change. html designs are still relatively simple to modify (or throw out). That's not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.
...
We [also] start with the interface so we can see how the app looks and feels from the beginning. It's constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you're dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later. 

As I said in the beginning, I advise you to read it, because for sure I cannot summarize it in a blog post, and also they sure it delivers the idea more than I do. I also may buy it as a hard-copy although it is available on line for free as a thank you gesture for those who wrote it.

P.S. I wish I can also adapt those ideas to other things other than software development, my day job is a Presales Manager, so why not apply this to both Network Design, Technical Sales and Team Management. Also some ideas here can be adapted to something totally different like drawing, or as Patrick Lafleur put it: "I really got over the "get into details right away" attitude after I took some drawing classes...If you begin to draw the details right away you can be sure that the drawing is going to suck. In fact, you are completely missing the point. You should begin by getting your proportions right for the whole scene. Then you sketch the largest objects in your scene, up to the smallest one. The sketch must be very loose up to this point. Then you can proceed with shading which consists of bringing volume to life. You begin with only three tones (light, medium, dark). This gives you a tonal sketch. Then for each portion of your drawing you reevaluate three tonal shades and apply them. Do it until the volumes are there (requires multiple iteration) ..."