Comments on: Formula for project success

By: Nick

Nick — Wed, 04 Jan 2012 19:42:00 +0000

Yeah, I’ve seen this too in a few places.

I’ve also seen that minor changes take ages and requires extensive testing because it could have so many side effects and is not covered by tests.

There’s always a quick way – and sometimes the quick way is good enough. It might be the extra few days that gets you to market first – making you the million and not the competitor next door.

Imagine your competitor has a clean code base, though, that allows them to throw on new new features at a rates of not – the customers are loving all of them. If you code is holding you back you might just regret your short term win.

By: Andrew Ogg

Andrew Ogg — Wed, 04 Jan 2012 14:37:00 +0000

But the thing is, Chad’s post wasn’t about maintainability or even “bad code”, it “Fubu is better than Rails, here’s why”, so really this is moot.

With Rails, it’s easy to build maintainable, “good” code, even if it doesn’t meet every single one of Chad’s narrow guidelines as a good Web Framework.

By: Alper

Alper — Wed, 04 Jan 2012 14:15:00 +0000

I second JDN. Currently working with a market leader software product. The code is not what you would call “good” code. However, users seem to like it and it generates value for the company even though it is not easy to maintain
(No tests, duplicate code etc.) . I agree that the software would generate much more value had it been maintainable.
In my experience, bad code can and sometimes does generate value.

By: jdn

jdn — Wed, 04 Jan 2012 06:19:00 +0000

I’ve worked with ‘bad code’ that has generated hundreds of millions of dollars, even though it was a maintenance suck-fest.

I’d call that value.

By: Matt Honeycutt

Matt Honeycutt — Wed, 04 Jan 2012 06:07:00 +0000

I agree with nlaq. The notion that “bad code” can still deliver value in the long wrong is a myth. The *vast* majority of development cost is in *maintenance* and not in initial development. We now have decades of empirical evidence to back this up, yet developers still seem to ignore it and focus on the short-term win.

By: Anonymous

Anonymous — Tue, 03 Jan 2012 18:52:00 +0000

No. No no no no no no no no no no no no no no.

Why? Because terrible code wastes developer time and effort and costs the company tons of money compared to better code; in bugfixes and development time to add features. Is “better code” bug free? No. But better code will always be easier to debug and fix.

Basically, if what you said is true, then you must be a developer who writes entire applications in one shot, doesn’t ever cause bugs, and doesn’t ever get asked to add features. I highly doubt this is the case.

If your managers don’t understand how important it is to write good code, perhaps it’s time to either educate them or look for a different job; as I shudder to think of how a company like that would treat developers.

By: Anonymous

Anonymous — Tue, 03 Jan 2012 18:36:00 +0000

I think there’s arguments for both. But I haven’t been in many situations where at some level I don’t have to set expectations of what the customer is going to get for their money.

By: Anonymous

Anonymous — Tue, 03 Jan 2012 17:20:00 +0000

I’d actually make the “what you code” 75% here; very often how doesn’t matter unless what is very successful and you get that 2nd shot at determining what.

By: Chris Bristol

Chris Bristol — Tue, 03 Jan 2012 17:06:00 +0000

“Understand what you’re building, what the vectors of change will be, how large the application will be, how complex in which areas it will be, and let that drive your decisions on what framework/technology/patterns to use. ”

That sounds pretty difficult. I mean, sure, you should do some upfront analysis to assess the situation and hopefully have a loose roadmap for future goals/directions, but the farther into the future you look, the less predictable your plans are. I’ve been involved in a few projects that started out small, and then organically grew into quite large monoliths. No one saw that coming when the project started out. All I’m really getting at is that it is quite difficult, if not impossible, to get accurate answers to those questions in many situations.

I would also say that success on one side of the equation doesn’t correlate with success on the other. You can write clean, well written code all day, but if it doesn’t meet the business requirements, its still a failure. You can also do a great job of meeting the business requirements, come in on time/budget/etc… and to turn out a technical nightmare.

By: Jason Meckley

Jason Meckley — Tue, 03 Jan 2012 15:16:00 +0000

I agree with digitalBush on this matter. The success of an application is measured by how it improves the company. Whether or not the code is clean only matters to the developer.