

Every line of code is a user interface - clawrencewenham
http://sites.google.com/site/yacoset/Home/every-line-of-code-is-a-user-interface

======
emehrkay
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.

Great read, thanks

------
jcapote
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.

~~~
flyhighplato
I think the headline and the blog entry is saying that every line of code is
going to be an interface for someone. Whether for the purposes of reading or
using your code. Kind of stretching the user interface idea to this other
thing, too.

------
jorleif
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.

------
Erf
The article makes an eloquent case for the following:

Code is liability.

------
teeja
"the real asset of the company--the programmer"

Where does it get to the "adjust pay accordingly" part?

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

~~~
clawrencewenham
Yes they are, and thank you. I never have anything to submit to social news
sites that hasn't already been submitted by someone else, though. If I'm
breaking etiquette I'll stop.

~~~
nreece
A suggestion (also a request): please consider moving your articles/essays
from Google Sites to a blogging service (with an RSS feed) like WordPress or
BlogSpot. Google Sites may be viable for static sites, but it becomes
difficult to follow it as a journal.

------
dasil003
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.

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

------
silentOpen
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.

~~~
roundsquare
Even then it depends. If you are optimizing across computational cycles then I
think this article applies (simple example would be a better sort algorithm).
If you are optimizing across data retrieval then yeah, your probably right,
its much harder to have good separation. Luckily, in this case, your algorithm
might still be useful even if the platform changes (unless data retrieval and
storage is optimized in the new platform to the degree that your nice
algorithm just isn't worth keeping).

