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


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.