Michal Charemza

There are virtually infinite options on how to split up all but the most trivial pieces of software engineering work, but rarely is emphasis placed on the skill of making that choice. But this choice is extremely important: the order in which work is done affects how frequently feedback is received (even from just running the code yourself) and so can seriously affect how successful projects are in the long term.

Emphasis is all too frequently put on the final properties of systems, as if components are made all at once in a single step. Even skipping over any iterative versus waterfall debate, a person can only do a single thing at once (or write one prompt at once 😜): you still have to decide to write one line of code first, another line of code second, and so on. As a parallel imagine if in other professions the order in which to do work was not a primary consideration: that would be madness.

In terms of what to do about this, my main suspicion is that a cultural shift is needed, and skills will be developed from that. Engineers must be encouraged to internalise that the order of the work they do is of primary consequence, and they must be empowered to continually set that order. I think also others in the organisation must also understand that while designs and plans are in general good, feedback from real use will so often suggest changes, and it's almost always better for such changes to happen early than late (or worse, not at all).

This is one of the several reasons I (with others) have written the "Deliver value daily" manifesto. Our claim (backed up at least from our own experience) is that a focus on small increments of at most day-sized work really helps with making decisions on what to do when.