As I’ve worked through almost two decades as a software developer, I’ve often wondered about the relationship between time and features. Basically, should the ‘explainability’ of a feature be proportional to its time to develop. I think it should. This can be generalized as: A small feature should take a small time to develop.
In physics, a quantum is the smallest divisible amount of energy that a thing can have. In software, I think that a ‘Quantum of Programming’ is the smallest unit of work that is actually a piece of usable software.
Take, for instance, adding a field, with basic validation, to an application. I feel that the requirement (or use case, etc): “I need a field to indicate the number of units that a person is interested in purchasing” should be one of the shortest and most predictable tasks. Now, there might be some crazy other requirement baked in here, but I find myself allocating lots of tasks like that to my team. Often, that task is a prerequisite to the business logic that ties it to the rest of an application.
So the deeper question, given a somewhat consistent architecture and 3-5 tiers to work through, is how long should one take to do this, and how many a developer should be able to do in an 8 hour day?
I’d say that the longest allowable time for this sort of feature is 30 minutes, compressible to 15 if the back-end and front-end developers can operate in parallel. This, if the back-end developers can do the database, procedures, and middle-tier, and the front-end developer can build the view model and UI, and end with the service call and mapper last, it should be possible to add ~12 or more fields a day, assuming each is on a different story and requires separate check-ins and tracking.
There is a sanity check here too: if someone told you that adding a field will take one person-day, how would you feel? I was once told that adding a DHCP lease for a machine was a multi-day affair, and given that I had done it myself before, I was pretty sure that that was a ‘padded’ estimate, given that usually that is a few mouse clicks. Maybe an hour? not even.
At the core of growing developer efficiency is the awareness that small tasks like this need to be compressed as much as possible, and tooling ought to support this, so that these minor tasks can be done quickly and with high quality, allowing developers to focus on the more complex tasks.
Later: should junior developers handle all this?