Formula for project success

In light of recent conversations around ActiveRecord and Rails, I thought it might be important to recognize the factors in a project success, in terms of the code produced:


In order for a software project to be successful, two things matter. What you code (the features you choose to develop) and how you code it (what technology you use, how easy it is to change, etc.)

These two constraints balance against each other, and neither is really more important than the other. If you code crap relative to what you need to code, then what you deliver won’t be good. However, it’s also important to recognize what drives what:


That is, what ever features/design/scope of what you’re building should drive the architecture/style/technology/patterns of how you code it. Picking the right before the left is putting the cart before the horse. 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.

Once you know HOW to use a technology, the next step is to know WHEN to use that technology, and more importantly, when not to. Clients don’t care about code, but they do care about a bad product. Know what’s important here, and make sure that the code is merely the means (a very important means) to an end.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Rant. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Anonymous

    Thanks for bringing some sanity to the new year. I might would even go so far as to say the “what” matters way more than the “how”. I’ve seen (and written a few) awful applications that were successful because they met the business need.

  • jdn

    This post is too reasonable.  Needs to be more ‘flamboyant’ and ‘inflammatory’.  ;)

  • Jason Meckley

    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.

    • Anonymous

      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.

      • 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. 

        • jdn

          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.

          • 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.

  • Chris Bristol

    “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.

    • Anonymous

      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.

  • Anonymous

    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.

  • Alper

    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. 

    • 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.