Rob Cook


Home | Donate

End to end programming


2021-03-13

The sooner you get to a proof of concept, the sooner you know where the real problems are.

In my early days of programming I used to build up solutions in layers. Each one would aim to follow best practices, unit testing, documentation comments, robust error handling and logging. This seemed like the right way to do things. It certainly chimed with the content of books on the subject.

The problem with this approach was the time it took to get to a working solution. That is, a solution that did the thing it was meant to. A lot of time was spent with layers that did stuff, proved correct only via unit tests. Nothing hung together from beginning to end. Integration testing was largely impossible, because all the bits that needed integrating didn't exist yet.

More recently I have gone for the rapid coding of an end to end solution. I still have layers to organise the code, but I'm aiming for what video game developers call a vertical slice. This is a piece of complete functionality from end to end. It acts as a proof of concept for the design. Is this lovely diagram going to hang together when implemented in code? Where are the real pain points in the design?

When coding in this fashion I largely ignore all the things you are supposed to do. No unit tests, no documentation, the simplest of error handling, and maybe some basic logging. If I need insight into the workings of the code at this point, I use a debugger. (In fact most of the time is spent in the debugger.)

I want to get a working end to end process as quickly as possible. I want to answer the question "will this approach work?". I want to know what the difficult bits are going to be. Once I get there, I can shape the rest of the design around these findings.

Think of it like building a spiders web. You start with a single delicate strand that links point A to point B. If that holds, you work back and forward across the strand filling out the web.

I believe this is a better way to build software. Too much time is often spent crafting a nice box (architecture) to hold all the parts, only to find out near the end that the parts don't all fit in.

end