2 ms·

One aspect of the problem is that whenever I need to build a particular system, the parts of that future system that are well understood system, with well under

One aspect of the problem is that whenever I need to build a particular system, the parts of that future system that are well understood system, with well understood tooling take almost no work - those either are available as part of a well-known framework or can be trivially included from a well-known library. All the work that remains, all the work that consumes most of the time of programmers is the work where either that parts of the system is not yet well understood, or where well understood tooling is not available. I'm not seeing the "factory" or "bricklaying" work anywhere, it has been automated or converted to reusable components or frameworks. Whenever I see people spending a lot of time on systems that could be "factory" work, the situation is that it could be "factory" work if and only if the system requirements and details were properly understood, and these people were mostly working and re-working on understanding and misunderstanding what's actually needed - and there's no way around that. Once they've understood it, any "factory" work part is quick and trivial to the point of being irrelevant in metrics. So my point is everything that we need from software engineering practices is tools and practices to manage the part that isn't "factory" work, the process of understanding the details of the systems that we haven't built yet.

TeMPOraL 6y ago
There is a third class of problems in coding that, at least for me, takes most of the time - definitely more than exploratory work. That class is what I call code bureaucracy - the part where you write code that shuffles and transforms data between components, or manages components. The components themselves may be well understood and already built, but they're probably nowhere near each other and have incompatible interfaces. Note it's not the same as "glue code". Writing glue code is a small subset of code bureaucracy, that happens only at the boundaries. True code bureaucracy begins when you discover that two components that need to communicate are on opposite sides of the system, and you need to carefully route a new path between them through half a project.
thesz 6y ago
You are using "factory produced" code every time you use any optimizing compiler for typical general purpose language. Compiler optimization phase ordering is NP-hard for every program being optimized and compiler writers cannot abstract that away to reusable components or frameworks.

TeMPOraL 6y ago

There is a third class of problems in coding that, at least for me, takes most of the time - definitely more than exploratory work. That class is what I call code bureaucracy - the part where you write code that shuffles and transforms data between components, or manages components. The components themselves may be well understood and already built, but they're probably nowhere near each other and have incompatible interfaces. Note it's not the same as "glue code". Writing glue code is a small subset of code bureaucracy, that happens only at the boundaries. True code bureaucracy begins when you discover that two components that need to communicate are on opposite sides of the system, and you need to carefully route a new path between them through half a project.

thesz 6y ago

You are using "factory produced" code every time you use any optimizing compiler for typical general purpose language. Compiler optimization phase ordering is NP-hard for every program being optimized and compiler writers cannot abstract that away to reusable components or frameworks.