in Search

Do you Twitter? Follow us @CodeBetter

Greg Young [MVP]

A Passing Thought

In a long email I wrote tonight I wrote a few words that should stay in every developer's mind and to me personally they represent a step in my own evolution.... for those who have known me for years (Craig, Brian, Steve, Toby, others).

Good, even great software will never make money, it can only save money. It can nearly always be done cheaper, more simply to produce the same results.

Businesses survive by making money.

Good even great software is not necessary for a successful business.

We focus an incredible amount of our time on how to make "great" software .. How to make it maintainable, scalable, and performant.

Thinking back ... my most successful pieces of code have been complete hacks that others can easily attest to.

Two in particular come to mind:

Toby: The vacuum process and remote updating of sql databases in systems. We spent what 1-2 days on both? Neither were well thought out/scalable but they were probably the most valuable features delivered.

My entire current system. I spoke about it at QCon a bit but we completed it in 12 days ... we later spent 11 months to do it 'right'. It was a complete hack but it made money.

80+% of systems fail for non-technical reasons (bad or late ideas, bad management, political failures) ... Why are we so focused on the technical reasons?

The only technical failures I have ever seen that needed to be fixed were of already successful systems. How many similar systems failed to the one that succeeded.

It is a calculated risk, but one that should be thought of.

Published Mar 18 2008, 05:27 AM by Greg

Comments

Ernst Kuschke said:

Too true mate.

# March 18, 2008 5:50 AM

Colin Jack said:

I guess one part of it is that as developers we cannot necessarily includence the non-technical reasons to the same agree?

# March 18, 2008 6:14 AM

Ray Houston said:

>Why are we so focused on the technical reasons?

I think it's because we're engineers and we want to solve problems. We want to solve the problems that make software development difficult (not just the business problems). We know we can make software better. We wouldn't be engineers if we didn't.

# March 18, 2008 8:51 AM

Kyle Baley said:

Funny, I've been thinking along these lines recently too as I toil away on an application that will only ever be maintained by one, maybe two people in its entire lifetime. Easy to forget that when it comes right down to it, we're not actually in charge.

# March 18, 2008 9:27 AM

joelowrance said:

Where did that 80% number come from? Last I read it was 70%, and I was skeptical on the origins of that.

# March 18, 2008 9:30 AM

Peter Ritchie said:

I've noticed the same thing. I've worked on several successful pieces of software--almost all that I can remember became successful while they were essentially "hacks". No real processes were applied to their initial incubation, and yet they were successful despite of that. There's been some that have simply failed because of process.

Makes you wonder if we're focusing on the wrong things sometimes :-)

# March 18, 2008 9:39 AM

wekempf said:

"Good, even great software will never make money, it can only save money. It can nearly always be done cheaper, more simply to produce the same results." Tell that to all of the makers of consumer software, such as games, media players, etc. Ignoring that, you have some good points, but you state them like they are universal truths, and I don't think they are. The hack can be very beneficial... until it's deemed worthy to do more than it was originally intended and you spend more money in maintenance of the hack then you would have if a properly engineered solution were employed. I've worked on such hacks and can easily explain to you why good engineering practices are important.

# March 18, 2008 10:48 AM

Greg said:

wekempf you are right ...

There are some fringe cases where great software IS the business ... I should have framed my statement with that.

per: the "hack" sometimes the more expensive solution is better for the business due to other reasons ... quite simply:

With running software I make $100000 a month.

Hack takes 3 weeks to get working then 1 year to fix ..

Doing it right the first time takes 7 months ...

Development team for the sake of argument is contractors at a rate of 50K per month ...

the first one wins ... but it especially wins in cash flow at the riskiest part of the project (the beginning)

# March 18, 2008 11:14 AM

wekempf said:

I don't want to sound like I'm dismissing your points. I'm not, because in many cases your points are very valid. But let me add the counter argument. I worked on a project originally created by another team. The new team spent over 3 years maintaining the brittle code base, where fixing a bug would always introduce at least 2 more. I quit at the end of those three years. At that point in time, despite being in production, the application wasn't production worthy. A LOT more money was sunk in maintaining this monstrosity than was being earned by it being in production. Yes, that's a management mistake, no doubt. But if a rewrite had been done (we presented the case, with a conservative estimate of 3 months), at the end of the three years I'd put up with the monstrosity, the product could have actually been saving a lot more than was being spent on maintenance. It's economics. Initially, the hack is the clear winner. If a project is scaled (either the length of time it's in production, or the number of installed bases, or other criteria) up, however, there's a point at which maintaining the hack becomes more expensive, and you should have built a more maintainable piece of software to begin with. Like so many other aspects of IT management, you need to be able to predict how much a project needs to scale and whether or not that means a greater profit/savings can be made with the hack or the properly engineered solution.

# March 18, 2008 11:42 AM

Bryan Reynolds said:

Agreed!

# March 18, 2008 12:20 PM

Greg said:

wekempf: that sounds like a project that had succeeded but noone ever paid the piper.

bad management is bad management you can't have your cake and eat it too.

My point is that most of these systems already fail for non-technical reasons ... the amount of time you save in the 9/10 (or whatever) systems that never actually need to scale or never need to be maintainable because they just die makes up for the 1/10 where you have to rewrite a successful project.

# March 18, 2008 1:08 PM

AndyB said:

Greg I guess the reason we focus on the technical reasons is that these are the only elements we as developers have control over. Its mitigating the risk as much as we can. Pragmatically of course.

# March 25, 2008 7:28 AM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

This Blog

Home

Syndication

News

Greg Young [MVP]

A Passing Thought

Comments

Ernst Kuschke said:

Colin Jack said:

Ray Houston said:

Kyle Baley said:

joelowrance said:

Peter Ritchie said:

wekempf said:

Greg said:

wekempf said:

Bryan Reynolds said:

Greg said:

AndyB said:

Leave a Comment

This Blog

Syndication

Recent Posts

Tags

News

Archives