“The Lazy, Clever Programmer: A Compendium Of Code Reuse & Recycling”

“As developers, once we start separating our code into abstract ontological typologies, we make use of the human mind’s phenomenal ability to work with types. Our code becomes less about jump tables and registers and more about users, email messages and images. What once was a problem of allocating resources and operations within the computer becomes an abstract, logical problem within a collection of objects….Over time, by constantly working to reuse our own code, we choose practices that work well for ourselves and discard practices that don’t work as well or slow down our workflow. For developers flying solo or those working on small projects, this evolutionary process is a sufficient way of going about things. But there’s trouble when we add other players into the mix–other developers, a user interface person, a database person, a sysadmin, a project mana-jerk: as a developer, they don’t have access to our ‘experience’ of the code and we don’t have access to theirs. ”

- Edgar Hassler: Link.

Via Slashdot: Link.

“A group of 10 people within a large organization is a kind of fake tribe. The number of people you interact with is about right. But something is missing: individual initiative.”
- Paul Graham

Paul Graham on the anthropology of big companies versus small companies:

What’s so unnatural about working for a big company? The root of the problem is that humans weren’t meant to work in such large groups.

Another thing you notice when you see animals in the wild is that each species thrives in groups of a certain size. A herd of impalas might have 100 adults; baboons maybe 20; lions rarely 10. Humans also seem designed to work in groups, and what I’ve read about hunter-gatherers accords with research on organizations and my own experience to suggest roughly what the ideal size is: groups of 8 work well; by 20 they’re getting hard to manage; and a group of 50 is really unwieldy.

Whatever the upper limit is, we are clearly not meant to work in groups of several hundred. And yet — for reasons having more to do with technology than human nature — a great many people work for companies with hundreds or thousands of employees.

Companies know groups that large wouldn’t work, so they divide themselves into units small enough to work together.

… Each group tries its best to work as if it were the small group of individuals that humans were designed to work in. That was the point of creating it. And when you propagate that constraint, the result is that each person gets freedom of action in inverse proportion to the size of the entire tree.

… A group of 10 people within a large organization is a kind of fake tribe. The number of people you interact with is about right. But something is missing: individual initiative. Tribes of hunter-gatherers have more freedom. The leaders have a little more power than other members of the tribe, but they don’t generally tell them what to do and when the way a boss can.

… The restrictiveness of big company jobs is particularly hard on programmers, because the essence of programming is to build new things. Sales people make much the same pitches every day; support people answer much the same questions; but once you’ve written a piece of code you don’t need to write it again. So a programmer working as programmers are meant to is always making new things. And when you’re part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you’re going to face resistance when you do something new.

… Working for oneself, or at least for a small group, is the natural way for programmers to live. Founders arriving at Y Combinator often have the downtrodden air of refugees. Three months later they’re transformed: they have so much more confidence that they seem as if they’ve grown several inches taller. Strange as this sounds, they seem both more worried and happier at the same time. Which is exactly how I’d describe the way lions seem in the wild.

- Paul Graham, March 2008: Link.

Via NewsVine: Link.

Here’s a story I like to tell:

I started programming when I was fifteen. (Actually, I wrote my very first BASIC program when I was ten years old, but that’s another story.) I’m now forty-six, so you can see I have some experience. Anyway, when I was fifteen, my dad taught me the rudiments of structured programming. He was a programmer himself, for the Star-Tribune.

Something he said has always stuck with me. He said, what usually happens is this: Management issues some directives; the programmers fulfill the directives; the end users try to use the programs — and things go wrong because the end users were never consulted about what kind of tools they need to do their jobs.

The successful programmer, dad said, is the one who first goes and sits down with the end users, talks to them about their jobs, finds out what they really need — then integrates this knowledge with Management directives. He called this “going native” (before he was a programmer, he took his degree in anthropology).

I’ve always taken this to heart, and in this sense, I’ve got something like thirty years experience in good interface design. Of course, I don’t actually say this on my resume, it’s kind of silly. But it’s a great story, and I think it illustrates the approach I take to my work.

- Karl Jones

“Talking about a software development schedule more than a year out is like talking about where we go after we die. Everyone has some idea where we’ll end up, but those ideas differ wildly, and there’s a lack of solid evidence to support any of them.” - Kyle Wilson

There’s not really any good way to measure the complexity or scale of a piece of software …. Lines of code is a lousy metric, but it’s the only one we’ve got …. The Feynman report on the Challenger disaster says the shuttle was running 250,000 lines of code. An F-22 fighter jet runs 1.7 million lines of code. What does this tell us about the relative complexity of these programs? Not a whole lot.

I believe that the following statement is an axiom of software development:

It is impossible, by examining any significant piece of completed code, to determine within a factor of two how many man-hours it took to produce that code.

And the corollary:

If you can’t tell how long a piece of code would take when you have the finished product available, what chance do you think you have before the first line of code is written?

Talking about a software development schedule more than a year out is like talking about where we go after we die. Everyone has some idea where we’ll end up, but those ideas differ wildly, and there’s a lack of solid evidence to support any of them.

- Kyle Wilson: August 19, 2007: GameArchitect.net: Link.

Via Dave’s Picks: Link.

Have you ever wondered how software projects result in failure?

This helpful flowchart explains the process:

Via Worse Than Failure.

Here’s one for the software developer in all of us:

“It’s absolutely critical … to not think of these layers as persistence, business, and presentation. Database, processing, and user interface are much more appropriate terms.”

[I]t’s completely infeasible to encapsulate an application’s business logic into a single layer. It’s also logically impossible.

By the time a developer creates the perfect persistence layer — something that takes in any type of data, tucks it away somewhere, and provides an easy mechanism to retrieve it — he has created a separate infrastructure application. Recreated, actually. The operating system’s file system already does exactly that.

By the time a developer creates the perfect presentation layer — something that takes in any type of data and displays it in a flexible manner — he too has recreated an infrastructure application. ASP/PHP/etc with HTML already does a fantastic job of implementing that goal.

There is absolutely nothing wrong with having a multi-layered application. In many cases, anything but that would be a bad design. It’s absolutely critical, however, to not think of these layers as persistence, business, and presentation. Database, processing, and user interface are much more appropriate terms.

- Alex Papadimoulis @ Worse Than Failure: Link.

Big Ball of Mud

“Complete rubbish” sums it up nicely.

There’s a pattern for this recommendation, and it’s very common — The Big Ball of Mud.

- Comment @ WTF: Link.

Business Logic: the Junk Drawer

The business layer is not mythical, it’s simply done poorly in most instances because most development departments have no definition of what is business logic and what is presentation logic or database logic.

When I separate, I ask myself what I am doing in a class. If my class exists only to enable display, then it’s view logic. Sure there’s page-flow which is defined by the customer, but it’s still the way the interface works, not the way the application processes data.

What about when the class does both, enables a view and implements business logic? The answer to that is pretty simple … your class is doing too much.

Persistence logic should pretty simple. There should be a way to find, create, update, and delete. Anything more than that is business logic.

I have a fourth class, that is utilities. All code that does something that has nothing to do with the application like xml parsing or string utilities(yes I know there are a ton of them them available to download, but this is an example) goes in the utilities.

Everything else is business logic. In my mind, if you correctly define the other three, business logic is like the junk drawer because it’s such a broad category.

- Comment @ WTF: Link.

Understanding the Problem Domain

As programmers we try to scrape by learning the least we have to about the problem domain, and instead lean heavily on people qualified to properly understand it.

Unfortunately, this means we cannot look ahead and we make some pretty stupid design decisions. A lot of the needless complexity and “over engineering” comes from a poor grasp of the actual problem. Meanwhile, we understand the technical issues very well, and so we quite properly manage to slot them into time-tested patterns.

- Comment @ WTF: Link.