lesscode.org


What the hell is going on here?  

By Ryan Tomayko under Then they laugh at you..., Theory on 09. July 2005

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:

3 Responses to “What the hell is going on here?”

  1. David O'Hara:

    After reading thru more of your posts via what I assume to be your personal blog, I have a much better understanding of what you’re pushing for here and I have to say that I’m in agreement. I have had several conversations with co-workers and associates around some of the ideas and I understand that you’re not breaking new ground here, but since I’ve never been on it, it’s new ground to me. :) Since I’m basically a .NET guy, my knowledge of technologies such as PHP and Ruby are minimal (but I’m learning them) and I have pretty much no idea what Python is about - other than it’s a language and the files end in py. ;) I do understand though that what you’re after is a fundamental change in paradigms - utilization of what we’ve got right now in the most (more?) effective manner for the issues of right now. The tools that we have aren’t broken; they’re simply being using in a wrong or suboptimal fashion. And that, my friend, is of great interest. Keep up the great work and I look forward to future discussions.
    (Sorry if I get a little long winded but my “wheels” are turning…)

    comment at 11. July 2005

  2. Eric Hawthorne:

    Re: the theory that great software is evolutionary and not “intelligently designed.” Ok so let’s take the case of Netscape Communicator. It did its job, browsing the web, but due to its rapidly executed, agile evolution, it turned into a large hairball of software. Starting over again with Mozilla then firefox was really saying. Look. We have to have some strong software architectural and design principles if we’re going to create a sustainable, extensible code base next time round. That wasn’t achieved by blind evolutionary luck, but by some intensive, careful thinking by a few folks upfront. Designing is achieving simple and elegant solutions to multi-constraint problems, by applying

    1. careful, wide-ranging associative and analogizing thought,
    2. dialectic discussions, AND
    3. experimentation.

    The “code evolution” path you seem to advocate amounts to favoring only the last of these three methods of designing and realizing good code. It amounts to saying: It’s too hard to think (imagine, model) a lot up front, and it’s too hard to communicate about these models in design-language-and-pictures, so I’ll just code, then you’ll see. A judicious mix of all three methods will work better in the long run. We have big brains people, let’s use them.

    comment at 10. June 2006

  3. Aristotle Pagaltzis:

    Eric: some people would argue that throwing away all of the old codebase set the project back for years and allowed the competition to eats its lunch… others yet would argue the new codebase is byzantine.

    We have big brains, but we have proven ourselves notoriously incapable of predicting emergent behaviour in complex systems correctly.

    comment at 10. June 2006