If you are reading this, your codebase is probably the lifeblood of your business or the organization you work for. As the technical co-founder of a few startups, the excuse that we are building a “minimum viable product” in order to write bad code is not an idea that is foreign to me. The Lean Startup methodology, which birthed the notion of MVP, impresses the idea of getting to market quickly with a limited feature set in order to learn more and iterate on feedback. The concept is popular and has had a great deal of influence on startups and larger organizations alike. The same basic concepts have clearly become the consensus for software development in general. Agile software management provides the same wisdom — that the only certainty is uncertainty and we need not map out the entire solution prematurely.

The problem I see is that people take the ideas of “lean” and “agile” and use them as excuses to simply rush things out the door more quickly while taking on massive amounts of technical debt. I understand the situations that lead to this practice: Time is a scarce resource and your funding is not infinite. I think the problem, though, is that people are not actually building minimum viable product, with a limited feature set that gets the job done. They are building feature-complete solutions built quickly on extremely shaky underpinnings.

“Feature creep” is always lurking around the corner and it requires tremendous discipline to avoid. When an organization, big or small, demands the advanced feature set of the established competitors while still enforcing the idea that this must be out the door in two weeks, programmers often have to write terrible code in order to get it done.

If you are a non-technical part of a team, it is really hard to understand how burdensome it can be to maintain and debug this kind of system. Coders will burn out and quit if this burden is forced upon them with too much regularity, and the organizational burden is that crappy code will be impossible to change. When the programmer made magic happen and got the entire application out the door in a matter of weeks, she likely did so by cutting corners and building a very shaky system. When the feedback on the initial release comes back and changes must be made, those changes will be incredibly difficult to jam into the spaghetti code that the application runs on — not to mention the time and energy required to put out fires in the form of critical bugs. Even though the software was initially shipped very quickly, a lack of attention to quality early on has doomed this project. You can get an amazing amount done in a very short amount of time if you mortgage the future to do so.

Some amount of technical debt — that is, the eventual consequences of any software system’s design — is inevitable because of uncertainty. No software is without bugs, but as a guiding principle, product developers should try to limit feature needs in order to take the burden off of the technical infrastructure, rather than cutting corners in the technical infrastructure in order make the software feature-complete. In practice, limiting the scope of features in a project comes in basic forms: Doing away with the need for the feature right now or using an external service to provide the feature to you or your customers. Irrespective of the technical benefits of focus, building scalpels instead of swiss-army knives is a good metaphor to live by in business.

The emphasis is on fostering an environment where good code is appreciated. This does not mean taking forever to ship or being scared to put your software out into the wild. Programmers should be accepting of the existence of bugs and encouraged to ship their code early and often. If product decisions are inline with good code ideals, long term success will be achieved. The threshold between good and bad software is arbitrary and reasonably impossible to define, but the constraints we put in place in order to foster good or bad code are more easily communicated and adjudicated upon. Focus on these constraints and the MVP will get out the door in a timely manner and the project will be flexible enough that you will actually be able to act on the feedback that was the point of the tactic.