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.
Jay,
ReplyDeleteI see this all the time. But what I also see, and I believe is a much harder problem to effectively communicate (to both developers and business stakeholders), is that of "VWs not Alfas".
What the users usually need is a safe, affordable, reliable Golf, what they are often seduced by is the shiny stylish Alfa, which starts to rattle 2 miles from the showroom, and spends most of it's remaining life at the garage.
Matt.
Maybe the projects I work on are a different scope than you're talking about, but I've found quite often that solving the problem in a way that I can "change the engine" or "turn it into a convertible" fairly easily is important.
ReplyDeleteQuite often the problems that I get asked to solve by the business are really subsets of a more general problem that they really want solved. So I've gotten into the habit of making things reconfigurable or adaptable or otherwise serviceable so I don't have to build a bunch of different cars, as it were.
Like I said, maybe I'm working on a different scope. A lot of my projects deal with doing a small amount of work on a large volume of data.
Nice post Jay. Understanding and delivering what the customer truly needs is an important part of software/product development -- not always an easy task by itself.
ReplyDeleteHi Jay,
ReplyDeleteThank you for another interesting post. Am I right to read it as "do the simplest thing that works" (where "works" as defined with the customer is what determines if you're building a Civic or a Cadillac) or is there more to it?
HI Chris,
ReplyDeleteYes, you're reading it correctly. There's not really more to it.
The simplest thing that could possibly work is often used by programmers to other programmers and often in Agile circles. While I think it can apply more broadly, I thought there was value in writing something that focused more on the business and didn't have agile tendencies.
Cheers, Jay
Dan, I would agree with both statements. I deal with the same thing. I work on some projects that do require the planning for 'changing the engine' or 'turning it into a convertible'. If I didn't plan for these things up front, then I would create much more work for myself in the long run. So, as you said - these are projects of a different scope.
ReplyDeleteI think what Jay is referring to can even be related to client work. I wouldn't apply those principles to a client job where deliverables are agreed upon and I am not being paid to think through the engine swapping and conversions. I am being paid to deliver what is needed now. Truth is, they may never need an engine swap or conversion. You have to be realistic with the projects.
As programmers we often think in data, data connections, data modeling, and building DRY applications that allow for ease of plug and play with everything, and we tend to think of scalability before it is ever even an issue.
So, it is about scope of a project. Not all are going to fit this analogy, but I think this analogy is a darn good one.
Hi Jay,
ReplyDeleteThanks for the clarification. I really like the idea of applying this principle at the higher, business level the way you describe.
Best,
Chris
This, and your post on Hackers not needing to apply, ring so true in my experience too.
ReplyDeleteAs developers or consultants we must be communicating with the business to understand their actual requirement, not trusting blindly what the document in front of us prepared by the BA is saying the business want.
Ok, that last statement sounds very broad-brush, but at the very least I'd want the business user to be re-affirming what the analysis states.
However agile methodologies are with us now, meaning we don't have to rely on such documentation and keep dragging through the slow process of Change Requests etc., and good communication between business and developer are the basis of a clear and in-depth understanding of the actual requirements, usually leading to an app that the biz actually use and a far better meeting of their expectations.
You're right Jay, the analogy does break down quickly- primarily because the programmer builds from pure thought-stuff.
ReplyDeleteUsing scrum-style development processes increases the transparency and communication between the car owner and mechanic. Helps me, anyway.
ReplyDelete-=R