Every line of code is a user interface

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

42 17 17 years ago

sites.google.com

socratees2• 17 years ago

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

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.

LogicHoleFlaw• 17 years ago

Quality content is always welcome here. Keep it up!

socratees2• 17 years ago

You should also consider writing regularly. The whole yacoset googlesite was interesting.

wglb• 17 years ago

Dude, this is good stuff. Don't stop.

nreece• 17 years ago

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.

mhansen• 17 years ago

Thanks for posting, that was really eye-opening. I hadn't considered that my code would need to be ported. Read? Yes, but not ported.

jcapote• 17 years ago

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• 17 years ago

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.

Erf• 17 years ago

The article makes an eloquent case for the following:

Code is liability.

teeja• 17 years ago

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

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

silentOpen• 17 years ago

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• 17 years ago

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

emehrkay• 17 years ago

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

dasil003• 17 years ago

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• 17 years ago

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

jorleif• 17 years ago

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.

Every line of code is a user interface

Related Stories