Of the developers I know and respect (or who are worth their weight in gold code) have often expressed this negative feeling that occurs at the end of the project.

You know: The one where you feel like the code could be better, the architecture could be better, the feeling that there’s so much room for refactoring, and so on and on it goes.

It’s practically the total opposite of when a project starts. That is, you set out with this clear goal in mind of what you want to achieve and are excited by the prospect of building this pristine system that’s going to be a work of art – it’ll be some of the best code that you’ve ever written.

Until it’s not.

What is with that, anyway? Personally speaking, this is something that I’ve experienced on nearly every single project that I’ve ever worked.

This isn’t to say that there aren’t parts of projects that I’m really proud of, but it’s also admitting that there are plenty of places where something has come along, changes the course at some point through the project, and requires that I make some type of sacrifice as it relates to the code base.

Don’t get me wrong: This isn’t accusatory. Building solutions for other people is a process of discovering what works, what doesn’t, and what needs adjusting. You’re also learning more about the problem domain. It just so happens that the nature of our field allows us to make these course corrections along the way.

And that’s where the problem lies: You know the least about a project when you start out, and you know the most about a project when you’re done.

Yet, we set out to create these elegantly designed systems when we know the least about what we’re doing.

There should be no shame in that – it’s something that we all experience. On top of that, the longer you work in software, the more code you read, and the more articles, books, and material you try to consume, the more familiar with you get with common problems and are able to more easily head off these problems before they become, y’know, problems.

To be clear, this is not an excuse to write poor code for someone else and then to pass it off as “Well I just didn’t know as much when I started as when we finished.”

No.

Just as there are times in which you learn something new along the way, so are there times in which you’re able to refactor at least part of your system before releasing, or you’re able to come up with some improvements, or an architecture that fits so that the code can be easily adapted over time.

Regardless, don’t let the tension that comes with having to adjust your development change as you work throughout a project. It’s all part of the industry and it’s something that most of us continue to experience.

Category:
Articles

Join the conversation! 8 Comments

  1. Totally true. I look at this tension as your creative and ethical edge. It’s about having the humility to reality check your pride and capacity for self-deception and simple blind spots. If you don’t feel it, you may be dangerously overconfident — the opposite of imposter’s syndrome. If you feel it too much, you struggle to get anything done. The right place is in the middle, but it’s impossible to define for everyone. Some creative and intellectual work gives authors/creators the freedom to cut a draft for a massive novel in half or completely rewrite it seven times. That’s unlikely to be appreciated with code someone else is paying for.

    • I look at this tension as your creative and ethical edge. It’s about having the humility to reality check your pride and capacity for self-deception and simple blind spots.

      I think that’s a good way of putting it. Unfortunately, I think our field is filled with people who do far too good a job of letting other people tell us how good or bad we’re doing when they don’t really know the full context of what it is that we’re doing.

      That’s unlikely to be appreciated with code someone else is paying for.

      People who pay for code to be written usually assume that it’s going to be done well. After all, no one markets themselves in a way that’s going to say “I’m going to get this done but before I do, I’ll probably inject some whack code in here just to get it to work.”

      I don’t think good developers will actually release something like that, but to get something prototyped or onto staging quickly, they might.

      Anyway, you’re right – it won’t be appreciated by those who are paying for it. There’s an implicit level of trust that’s comes in these types of relationships.

  2. Yes Dan sometimes you just need Code that gets the job done, beautyfull or not like a car needs sometimes just 4 wheels to get you from A to B

  3. This one has made me stop and think..and yes, you are right.

    I wouldn’t consider myself a coder or even a developer, yet I have similar sentiments toward the tail end of any web project that I’m working on.

    I seem to know more about the problem at the end; I understand how my choice of elements will affect the solution; I know why I’m building the project.

    It is one clear sky..I see it all.. then I have to hand over the project just then.

    Sometimes there’s a bitter sweet feeling I have: like I could have done better to help the project and the client. Perhaps if I had known what I know now about the project, my pricing would have been better positioned for value. All these things, and then I have to hand over the project just then.

    About the same time, a new project arrives on the horizon, all priced up and ready to go, but I understand absolutely nothing about it…

    At times I even wonder if it would be wiser to offer a price/value proposition at the end of a project, rather than at inception…just saying.

    Thanks for adding words to that sentiment. I think I understand it better now.

  4. This is so true however also inevitable. The thing is that it applies not only to the code but to the project itself, by which I mean that when you have delivered it and it has been used for a while there will be a whole host of feature requests since those commissioning the project put down what they thought they wanted then realised when they were using it what they actually wanted. Have a look at http://stackoverflow.com/questions/3477706/development-cost-versus-maintenance-cost.

    I guess it’s also why AGILE development has become so popular.

    • @Andrew — That’s really good, a concrete, authoritative rule of thumb that you can throw at people who aren’t thinking about future and total costs. I’d go so far to say that it’s a bad idea to accept projects where this point has not been understood. That probably indicates an underlying lack of business sense/planning if not an unrealistic budget.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.