Destroy the Prototype

If you’re tasked with building something, build it properly the first time. New projects often require some exploratory development to become comfortable with a new platform. As soon as your done, start over when it’s time to build the real thing.

There’s absolutely no other excuse to prototype with real code. Use static pages or any other model representation of your project. Anything but code.

You should be treating every project like a production project. If you lower your standards in a prototype, you’ve already lost. They always end up in production, with just one more change request.


Shelf-life is a Multiplier

Be aware of the intended application shelf-life. A throw away agency campaign does not need the same level of craftsmanship as your companies flagship product which needs to support the company for the next decade.

If you pay for your poor design decisions for a decade without a major rewrite, the application will be riddled with complexities and repetition. If you over design a simple project, you may end up with either to much coffee to maintain, or be a little over budget.

What’s worse: 10-20% over budget now, or paying your development team staff an extra few years salary for maintenance, loss of morality, the inevitable churn and finally new staff training.

Domain-Driven-DesignSoftware ArchitectureSoftware Design

Designing away Complexity

Complexity in software is the result of poor design. It has nothing to do with the size of a codebase, but how well it articulates the problem it is solving. A solution should never be any more complex than its original problem domain. The domain should be stripped of ambuigity & noise, and cleanly represented by a concise model. Fail to do this, and every day complexity will be added trying to support an incorrect model.

Stop thinking about solutions in code, and take a step back, understand the problem, and solve it with your design.