lesscode.org

This is great:

“This is a Fisher Space Pen,” he said — a pen developed for NASA astronauts in space, a pen with ink that just keeps on flowing. A pen able to write upside down and even underwater.

“It’s sophisticated, it’s costly, it’s very nice and very shiny,” Geck said.

Geck is chief technology officer at SuSE Linux, an open-source software outfit now owned by Novell (Nasdaq: NOVL) , and he’s about to make his point: “The Russians just used a pencil.”

I can’t vouch for the rest of the article as I’m on my way out and it’s pretty long and businessy. However, it seems he has his facts a bit mixed up - it’s common knowledge that in Soviet Russia the pencils use you!

A big part of what we’re all trying to do is bring the complexity of our systems and working environments way down compared to that of the established industry. Complexity is a tricky concept, however, and I believe it is wise to understand when it is and isn’t okay to play the “too complex” card.

Bill de hÓra introduced me to the idea that the that’s not simple argument is often not very different from the that won’t scale argument we’ve all come to despise:

These days we are all complexity experts and simplicity mavens. Once upon a time a popular way to trash somebody’s technical design without having to bother to present a cogent argument was to point at it and say it would never scale. Today we just can call designs we don’t like complex - that’s even better because while it’s unlikely to happen, you can actually have a meaningful conversation about scale. Complexity on the other hand is comparatively vague - indeed there is only one simple definition of simplicity for software.

But David Meggison does an excellent job of describing why the simplicity argument is a healthy way of thinking about systems anyway:

… it’s really a fundamental change in the burden of proof (in the popular sense of the obligation to defend a position). With the rise of agile development and worse is better, we’ve shifted from “required until proven unnecessary” 10 years ago to “unnecessary until proven required” today, and I think that’s a change for the better — after all, if we’re uncertain either way, we might as well pick the option that requires less time and money. So when people say “the project is too complex,” what they’re really saying is “prove to me that these features are justified.”

He goes on to talk about the relationship between “unnecessary until proven required” and The Presumption of Innocence, which is widley considered to be an essential right of peoples belonging to a democratic society.

I propose that we adopt “unnecessary until proven required”, which is perhaps also known as YAGNI, as one of the “strength traits” that help ensure the successful evolution of a system.

I’m glad to see that there’s been a healthy amount of interest in the site and concept thus far. I want to talk a bit about scope because a majority of the questions seem to be coming from that direction.

A comment from David O’Hara:

I’ve been reading some of the links in your “About” and am quite curious about your ideas and philosophies on design. Hopefully, there will be some forthcoming posts on them. hint hint

Absolutely. Although, I think it will be more like relaying existing ideas and philosophies that have come about organically that I’ve been lucky enough to observe rather than anything I’ve personally sat down and figured out myself. Great systems are grown, not designed.

I can’t find the quote at the moment but I’d like to paraphrase Clay Shirky,

I’m a hopeless anti-visionary - I find that when I concentrate too heavily on what might happen in the future, I miss what’s working right now.

That’s 90% of this site’s premise. We have, at this very moment, a whole slew of great technologies that have come about organically through years of field experience that are being ignored and brushed aside by a large portion of the IT community because they are:

1. Simple
2. Not designed (in the Cathedral style)

In fact, you might consider lesscode.org an experiment to see how far we can push the concepts put forth in Shirky’s Situated Software combined with the theory that great software is evolutionary and not intelligently designed.

What happens all to often in collaborative peer development is that we find excellent ways of doing things but since there’s rarely an “expert” employed to evangelize and formalize these concepts or a PR department to prepare a press release, the concepts never reach the larger community mainstream or are perceived as being “unprofessional”. We need to turn that thinking around.

Many believe we need simply to adopt the PR and evangelism techniques of the established industry but that’s a mistake, IMO, and attempts to do so have failed in the past. There has to be a better way, and I think forward looking companies like Redmonk, Propylon, and 37signals are blazing that trail in different areas. They are not trying to adjust their radically different models to the established industry, they’re forcing the established industry to adjust to their model and they can because they know their model is better.

So I think the first step is to admit that our system of values are really very different from those of the established industry and to stop trying to pretend otherwise. Instead of trying to blend in, we should be distinguishing ourselves and doing a better job of explaining why we make the technology decisions we do. Because, I have to tell you, right now the majority of decision makers (in corporate IT at least) believe that J2EE (or whatever it’s called now) and .NET are the only platforms capable of producing “real” software. But don’t blame them, that’s what they’ve been told - we haven’t been vocal enough in rebutting the industry story.

If we’re going to make a run at this, we need to accept and state confidently that our practices are superior in many ways and then start putting some more definition around why that’s so. We need to bring the industry’s values in line with our in own. In many cases, this means convincing decision makers that values like buzz, “enterprise class”, and promised capability should be replaced with values like simplicity, strong team dynamics, and proven capability.

I really need to learn how to end a post; after two years of doing this, I’ve still not gotten the hang of it. But I’d like to leave you with some more bits of recent philosophy that I think are interesting and relevant:

• No more nails
• Frameworks should be extracted.
• Working code attracts people who want to code. Design documents attract people who want to talk about coding.
• Radical Simplification

For a really long time now I’ve wanted to get my development related projects, essays, and other ramblings into a more coherent place on the web. At the same time, I’ve been thinking a lot about this “movement” (for lack of a better word) that I’ve grown a small part of that is simplifying, humanizing, and opening up IT.

There’s a significant portion of the development community that’s just plain pissed off at the status quo and have begun pursuing radically different ways of building and delivering systems from what is now commonly accepted by the established industry. To our delight, we’re finding that There’s Plenty of Room at the Bottom and that the next big thing in IT should really be making it smaller.

We’re also finding that this new-think will not be accepted by the mainstream analyst firms, tech publications, and vendor powerhouses on simple merit. Pimping the latest acronym from the latest vendor with the latest money is a much easier way of bringing in stupid amounts of cash than is trying to move an industry forward in providing real value to actual people. So screw you guys - your goals are in direct competition with those of my customers.

As you can see, I’m a little bitter… But I’m also excited - we’re assembling a stack of tools and techniques that are demonstrably superior and yet somehow much simpler than those of the mainstream past. We’re starting companies and controlling our future and it just feels right.

So I’m proud to announce that lesscode.org is open for business. It’s still a work in progress but here are my goals for the place:

• Advocate, communicate, and discuss the happenings of the less movement.

• Provide tools and resources for like minded individuals to collaborate on projects (subversion, mailman, trac, etc).

I’m also prepared to chase funding in the form of hosting, bandwidth, admin time, etc. should their be significant interest in the concept.

We’re not using the web right.

I’m in the midst of gluing together a bunch of tools into a seemingly coherent whole. If you’d like a lesson in why clean HTML / CSS are important, take Wordpress, Trac, mailman, Docutils, and a homegrown Python documentation generating utility and try to make them all feel like a single integrated app. You’ve got 5 template languages, entirely different applications of HTML semantics, and more redundant CSS then should be dealt with by a sane person whose wish is to remain sane.

But is there really a better way? I sometimes wonder, if all of these systems exposed resources in a more pure data format (e.g. “web services”), would things be any easier? Sure, I’d be able to do a lot more and integrate them at a lower level but I don’t need that. Right now I need everyone to use really clean and basic HTML with some basic conventions on class and id attributes. I should be able to crank out 50-60 lines of CSS and easily attach it to each app.

XSLT could help here, but then again, it’s XSLT. And that’s the kind of complexity and correctness I’m trying to get away from.

Anyway, I should be launching in the next week or so. I’ve got two utilities cooking right now that just need some polish and then I hope have this thing off the ground.