Pimp my software
· 2009-06-23 09:00 by Thijs Kroesbergen for Brokenwire.NET
Everyone who has done some (serious?) software development knows that we have several different methods to run our project. We also know that not all methods are equally successful. But one of our favorite things to do is compare our ways of doing things with others in the more “traditional” trades.
So a little while ago I was watching MTV’s "Pimp My Ride", and then I was thinking, what would software development look like if we did it the “Pimp My Ride” way?
So let’s see what that would look like. For those of you who don’t know the Pimp My Ride TV show, it goes like this:
The show starts by showing a teenager with a banged up car. That car gets picked up by the shows host and brought to a garage. Then a team of mechanics goes wild on the car by remodeling it completely. Then the owner is brought in, the car is presented and a happy guy (or girl) leaves the shop with a new ride. If you want to see this for yourself, take a look at the MTV website.
Now let’s break that down into the parties involved. The core group of people involved is of course the team of mechanics. This team designs and builds the car. The way this team is composed is that several people with different specialties are brought together in the right mix. In our world this would be team of highly skilled software engineers. This way each member should have its own specialty like data-access, user interfaces and such. Perhaps the most important thing to notice is that all team members are involved from start to finish.
Then there’s the host of the show, he gets to pick up the car, monitor the work on it and deliver it back to the owner. In the software development world this could be the project manager with a bit of help from some sales guy perhaps.
Last but not least we have the owner of the crappy car. This is comparable our customer, who has a problem (a crappy car, or some complex business process) and needs someone to solve it for him.
That wraps up the parties involved, now lets move to the process.
At the start of each episode (project) the old car gets picked up from some lucky bastard by the presenter of the show, a rapper known as “Xzibit”. They chat a bit and X gets a pretty good idea about the likes and dislikes of the car’s owner. This translates to an combination of sales and analysis. There’s communication with the customer, and both the scope and the requirements are set. For example, the owner drives a VW Beetle (scope) and likes to sing (requirement).
Once this is done the car is brought back to the garage and the whole team gets to take a good look at it. Then they sit together and each specialist tells what he thinks that needs to be done to the car.
Lets see how that meeting works out…
Paint specialist:
“I’m gonna put on a base layer of toxic green paint, and then I’ll airbrush some hot flames on the side of this wicked car!”
User Interface guy:
“I’m going to design a WPF based interface with nice glowing buttons which animate on mouse-over”
Engine tuner:
“Let’s upgrade the engine so it can do 0-60mph in 2.9 seconds! For that I’ll use this nice turbocharger kit.”
Database guru:
“I recommend that we store our data in a clustered SQL Server database, and we’ll use LINQ for our data access layer. This way we will have performance and speedy development all at once!”
You get the point ;). This meeting is like the project kickoff. Here the architecture is determined and the individual components are defined.
Then they get to work. Each specialist does what he does best, and they work together as the gears of a well oiled machine. Sometimes they encounter something unexpected, but with all the knowledge they have on board they will continue to deliver the finished product right on schedule. This is actually exactly the same thing that is (or should be) happening in any software delivery process.
Finally during the last minutes before the car’s owner arrives the finishing touches, such as polishing the car, are applied. Then the big unveiling takes place, and a happy customer leaves the building.
“You’ve officially been pimped”
The handover of the car’s keys translates to the delivery phase in our world. This where the happy customer accepts the finished product. And a happy customer is what we are aiming for!
To conclude this rant, lets see why this “Pimp My Ride” process should work for software as well:
- We both do the same trick over and over again. Almost every application is an assembly of standard components, just like a car is build of standardized parts.
- A mechanic is just as much an expert in his field of work as a software engineer is. We know what we are doing…
- Both teams are used to delivering a the project in a fixed (or rather, predictable) amount of time.
- In the end a happy (paying) customer is all that matters. The customer tells what he wants, and that is just what he’ll get.
But of course there are some differences as well, so why doesn’t this work for software?
- The “architecture” of a car hasn’t really changed in the last decades (Or has it…?), for software we have many different solution for many different problems. So is creating software that much more complex?
- If you get back your once-rusty now-pimped car for free, without cash involved, you are not going to be very picky about requirements. Software is usually well paid for, so the delivered product has to live up to much more well defined expectations. Does this mean we can’t educate our customers on what to expect? Have you ever seen them building a flying car? No? Maybe because it IS possible, but its just very hard to get right. Now compare that to software, how many times do we say something just isn’t possible?
- Perhaps the size of software development projects isn’t as consistent as the size of a pimping-a-car project is. Some project are like building a bike, others could be the size of building a complete cruise ship. Then again, for completing such a huge project you need to split it up in manageable chunks anyway. So the real question is, how big should a project be to have the optimal size?
- We tend to separate our teams in architects, designers and builders. But in the Pimp My Ride team each member is a specialist in both designing and building his part, from start to finish.
It looks like this comparison doesn’t hold up too well (but I had fun trying it anyway). I do think that we like to over-complicate things because with software it’s so easy to create anything our mind can come up with. And because of our human nature we just love to try stuff that hasn’t been done before. Perhaps, given some more time and thought, the expectations for software will become just as clear as the expectations we have of a car.
So what do you think? Does any of this make sense? Is building software harder then building a custom car? Are we spoiled by all the options we have and do we over-complicate?
Quick Visual Studio Tip The madness of “exclusive” row locks