Fog Creek Software
Discussion Board

Speed of development

There are lots of books about writing high quality software.

In some fields, quality is not that hard to achieve, and what counts is the speed of development.

Many times your team must develop the software before the other team, and be first in the market.

So, speed of development can be crucial.

Is there any good book about developing applications fast?

I'm looking for a modern book which includes the latest advances such as RAD, agile methodologies, etc, and which should teach me how to organize a development process in order to get high speed, efficient development.

Tuesday, June 15, 2004

In what fields do you think quality is easy to achieve?

Ori Berger
Tuesday, June 15, 2004

I think "Rapid Development" by Steve McConnell is exactly the book you are after. It examines techniques for developing code faster and the sort of trade you may need to make to shorten development time.

Ian H.
Tuesday, June 15, 2004

Rapid Development: Taming Wild Software Schedules

Steve C. McConnell

Very good.

Tuesday, June 15, 2004

"I'm looking for a modern book ...."

You ain't going to find such a book. Not even Steve McConnell's first PM related book comes close to what you are looking for.

Curious George
Tuesday, June 15, 2004

I am currently reading . It's not bad for a quick read in the "I have a spare 90 minutes, lets get some quick mile-high intro on this" department.

Just me (Sir to you)
Tuesday, June 15, 2004

> ... the latest advances such as RAD

RAD was around at least as far back as 1992. It was associated with VB.

Tuesday, June 15, 2004

I think he means, it helps to go through several stages of development as opposed to cutting some aspects(testing?, documentation?) short because of time.  Maybe there are ways to produce a lot of code with the same amount of quality in a short period of time.  Oracle has something interesting setup, I was reading where they develop 24 hours a day because of their bases all over the world, so while the Americas are asleep, the India shop kick starts.

Berlin Brown
Tuesday, June 15, 2004

Have a look at

Cecilia Loureiro
Tuesday, June 15, 2004

"Test-Driven Development By Example"

Why test-driven?  Because I assume you want to be *finished* faster, not write code fast, then spend lots of time debugging.

A test is like a climber's piton, hammered into the side of the cliff you're scaling.  It takes a few moments to put it in, but it keeps you from falling and having to climb back up again.  If you're trying to go fast, you can't afford to do stuff over.

Interestingly, this also makes sense for refactoring.  If you get to a certain point and realize that you need to redo something because you can't get from point A to point B with the current state of the code, the tests will make sure you don't break any functionality you already had.  (To continue the climbing analogy, this is like having to climb back down a bit because of a dead end, but the higher pitons you put in can be your safety line without having to put new ones in.)

So, while tests don't contribute directly to you "climbing" faster, they *protect* your speed by making sure you never "fall" further than the distance you've put between them. 

The faster you're trying to go, therefore, the more tests you want to have when crossing tricky areas of the "cliff".

Phillip J. Eby
Tuesday, June 15, 2004

Yes, Beck's TDD.  Absolutely.

(By the way... RAD is an archaic term from the 80's.  And McConnell is equally pleistocene.  And while the employer he learned his ideas at, Microsoft, makes some good products, their programmer culture is kinda anachronistic, if not downright old-timey.)

Tuesday, June 15, 2004

Crystal Clear contains some useful material - not about coding techniques, but about processes for producting good software more rapidly.  See .  The book is due for publication later this year.

John Rusk
Tuesday, June 15, 2004

It has been my experience that if you want quality products faster, you will need to higher experienced and talented resources.

And this is expensive, which is why most companies shy away from the approach.
Tuesday, June 15, 2004

It all depends on the problem domain.  Be skeptical of particular books or methodologies, because they all spring from particular environments with different demands.  Developing C++ desktop apps ("rich clients" to use the parlance here) requires markedly different disciplines than video drivers, database-backed websites, a filesystem, a small desktop utility to calculate one-time passkeys, a flight reservation system, a warehouse scheduling system, a robot motion planning system, a Winamp plugin, a virus, a TCP stack, or any other of the myriad kinds of software out there.

As the previous poster said, one strong way to guarantee results is to pay for top talent.  Even that's not a guarantee that you will get results, because many other factors are involved, but it counts tremendously.

Thursday, June 17, 2004

*  Recent Topics

*  Fog Creek Home