One of the topics I mentioned in my agile fundamentals post is to get started faster. The design phase1 of most software development processes can usually take a significant amount of time. In a lean environment, everything must provide value, so what value does design offer and why do we do it?
Your design is a proof-of-concept
Simply put, your design is a proof-of-concept. It’s a paper2 exercise where you “implement” things using boxes and diagrams. You “test” your design by thinking through things like bottlenecks and dependencies.
Designing “on paper” is usually cheaper and faster than trying to implement it in code. You can make changes to the design by erasing and redrawing parts of it. You can easily throw out the design and start fresh. You can even reuse parts of other designs to accelerate the process.
What if implementation was as cheap and fast as designing on paper?
What if you could quickly throw together an application with minimal code and infrastructure? What if your inner dev loop was so fast that changes could be viewed instantly. What if you kept your codebase so lean that you weren’t bothered by the sunk cost fallacy and could have the confidence to add and remove things as needed?
If all these things were true, would you need an up-front “paper” design phase? Could you get started faster?
Technologies exist to support lean, fast inner dev loop, immediate feedback, and continuous refactoring.
On today’s web, patterns such as JamStack and most frameworks support hot reload. Hosting providers such as CloudFlare Pages support Continuous Deployment workflows, preview builds, and lightweight API’s. The tools exist for lightweight, fast, and iterative development. Only your ability to keep the code lean and continuously refactor is required to turn a proof-of-concept into a scalable, reliable, and sustainable product.
Consider with a lean, working proof-of-concept, and continuously refactor until it resembles a good design.
If…
- You have all the fundamentals in place that support a lean, fast inner dev loop, with continuous deployment
- You have the discipline to keep your code lean and high quality through good testing and observability practices
- You are experienced in good design patterns and know how to refactor into them instead of starting with them
Then…
- You should consider coding your POC instead of doing a “paper” up front software design phase.
Because…
- You will get started faster
- You will get real feedback quicker
- You will be producing value sooner
But…
- You will end up with a ball of mess if you don’t have the fundamentals in place.
- That said, if you don’t have the fundamentals in place, it’s unlikely that a paper design exercise will compensate enough to avoid that eventuality.
-
By “design phase”, I’m referring to the technical or architecture design of a system or product. But, it can also be applicable to UX design… why not implement your screens instead of drawing them? ↩︎
-
Paper… Powerpoint… UML… C4 Diagrams… whatever… it’s all a theoretical exercise until it’s a real system. ↩︎