This post originated from an RSS feed registered with Ruby Buzz
by Jay Fields.
Original Post: Civics not Cadillacs
Feed Title: Jay Fields Thoughts
Feed URL: http://blog.jayfields.com/rss.xml
Feed Description: Thoughts on Software Development
Back when I made $20,000 a year I bought a used Honda Civic. I needed something to get me from point A to point B fairly reliably. I was looking for the best deal given my requirements and I found a Civic that seemed to fit the bill. I had a good advantage as a buyer, I knew what I wanted and I knew approximately what it should cost. The car lasted for several years, and I was always happy with the purchase.
The story could be much different. If I knew less about what I was buying I would have had to rely on someone else. If I ended up relying on someone unqualified I might have ended up with a Cadillac. Cadillacs are fine cars, but on a $20,000 annual salary I did not need the beauty and luxury features of a Cadillac.
The analogy probably breaks down quickly, but the same basic idea applies to business software. Time after time I see developers delivering Cadillacs when Civics would have been acceptable. The business has no idea what the difference in cost is between a Civic and a Cadillac so, as any ignorant customer does, they smile, thank you, and walk away worrying that they got screwed.
Imagine walking 5 miles to work every day while someone is building you a car. You want a Civic, which you think can be built in 2 weeks. Instead, you get a Cadillac in 4 weeks -- at a much higher cost. You'd be upset, and yet this happens in software all the time. Even worse, you might get a Civic in 4 weeks, but it comes with assurances that if you ever want to change the engine or make it a convertible it can be done in 15 minutes. You'd be asking yourself: when did I ever say I wanted a new engine or a convertible? You had to walk 10 miles a day for 2 extra weeks to get your "ultra configurable" Civic.
It's time to fire your mechanic.
This happens a lot with hackers, which is why businesses should employ developers, not hackers. But, this behavior isn't exclusive to hackers. I've seen plenty of developers who prefer to deliver Cadillacs. I know I always appreciate Cadillac software solutions, but I always find myself asking if the business knows the cost of the Cadillac.
The solution is simple: increase collaboration and change the definition of success. Developers should constantly be talking to the business, but they also need to think in terms of business value instead of solution beauty. Successfully delivered applications can be used by the business to make or save money. The amount of money made or saved is often determined by how much collaboration occurred between the developers and the business. High collaboration ensures the business gets the application they expect. The collaboration also ensures the developers understand their impact to the business. If they make or save the company money with their applications, they've succeeded.
Making or saving money, that's why a business employes you -- and that's how you earn your salary.
Previous Topic
