Every line of code is a user interface

I understand the whole separation of concerns thing. This seems to take that ideal one step further. It makes me think of business logic being single apps that require a few arguments to run and that do one thing and does it damn well. The app can be written in whatever language, it can stay consistent, it is the environment that may change and how the app is being called in that environment. However, the app is like a little box and you give it args and it turns out whatever based on those args. Instantly makes me think of *nix's command-line functions.<p>Great read, thanks

Odd headline, didn't see how it matched the story, maybe I missed it. Nevertheless, this is an insightful article about why one should continuously re-evaluate the way they are doing things vs the way things are getting done in the industry.

I've done the same thing he describes, of building a large system that would be quite small with modern tools. I wonder what could be to alleviate the problem. Of course good factoring of code and using a high-level programming language so that the existing code-base is as small as possible help somewhat. It feels to me that the real solution would be to make a stronger separation between the business logic and the actual implementation. In a way the code for a piece of software is an overspecification of what that software should do. It contains both a set of decisions that are necessary for the problem, and some that are necessary for the actual implementation, but otherwise arbitrary. In some way, one should build a "problem model" that is executable. Then the actual system would interact with this domain model. Then when the software infrastructure improves, the problem solved presumably does not change as much and most of it could be reused.

The article makes an eloquent case for the following:<p>Code is liability.

"the real asset of the company--the programmer"<p>Where does it get to the "adjust pay accordingly" part?

@clawrencewenham, aren't these your own articles? Anyways, i like your writing. :)

This is a great story, but I wonder if it can be avoided. Properly factoring code is hard enough just with today's constraints. You have to think about readability, maintainability, regressions, performance, scalability, etc. Now you want to separate the lower-level bits from the business logic. That sounds nice, but it requires knowing what functionality is going to be obsoleted by some new framework in the future.

This can also be and intro to why Open Source is effective (and why Modern Perl is CPAN based).

It seems like this really depends on the nature of the code... for gluey stuff slinging data this may be true. For most algorithmic tasks, the coarser module should be preferred.