Lennart Regebro: Development workflow and architecture

Back in the stone-age, when I started programming, the main development paradigms was “bottom-up” or “top-down”. Essentially, if you created the overall structure of the program first, and then started filling out details, or did you implement low-level functions first and then composited them together.

I never did any of those, I tended to do “start-finish”, I start with the first thing that needed to happen in the program and go from there. It was hard to get it into a “workflow” of things to do that resulted in anything else. So I shunted the whole idea of “bottom-up” or “top-down” to the side, and apparently so did everyone else because people stopped talking about it. I also think that many frameworks enforce their own workflow on things, so it’s therefore become less relevant because if this.

The last few years I have however found myself doing a lot of bottom-up development, and that’s because my tool kit now includes test-driven-development (TDD)

My workflow currently looks more or less like this: I fiddle around, test things, look at what others have done and use it if I like it. If I don’t like it I do a bit of rough “start-finish” development until I start getting the “feel” for what I’m doing and a rough idea of what I need.

Then I start a new module, and use TDD (more or less). And since I use TDD, and need something that is easy to test, and that results in a bottom-up modular approach where classes tend to be very independent of each other and their environment, simply because that makes them easy to test. It wouldn’t be possible, at least for me, to do this unless I had a clear idea of what I want, which means trying it out first. But in the end, once I start the module and the tests, even though I usually end up copying in what I already had, this quickly tend to get thrown out.

But the end result is that TDD makes me a better programmer, and makes me write code that is clearer and more modular and can be refactored more easily. And this is because TDD more or less forced me to write bottom-up. So maybe that paradigm was less irrelevant than I thought.