So today is the last day of our first summer Internship Program. All-in-all, a huge success, both for Arc and for our first two interns–Alex and Ben. These two guys shattered any preconceived notions of ‘intern’ that we had going into this summer, which makes sense, as they’ve each been programming for over a decade (it just so happens that that represents more than half of their lives…). Seriously though, these two guys are brilliant–the bar for next year is high.

We learned a lot this summer about how to structure this Program going forward, particularly the size and scope of the efforts we should embark on, and how to structure their work within the company. I wish I could go back and do some things differently, but when I voiced that concern, both Alex and Ben were quick to let me know that they wouldn’t have had this summer any other way. Oftentimes, you learn more from challenging and ambitious efforts, than from safe work.

Anyway, don’t take my word for it, read Alex’s and Ben’s recaps, in their own words.

Thanks guys–good luck in school this year.

Until recently my conception of a software company consisted of two guys crammed into a former closet, surrounded by ashtrays stacked on ashtrays stacked on servers and other assorted hardware, both functioning and non. Being asthmatic, this never appealed to me. My only other imagining is Mike Judge’s, and as charming as the Initech boys were the corporate atmosphere is as strangling–if not more strangling–than the smoke-filled closet. Where, then, do I fit in?

Stereotypes aside,when all the news is about either two-man startups or huge, huge firms where does an intelligent, but relatively normal person fit it? I’m passionate about technology but not to the point where I’d have to give up my family, in this case my dog, to sing the startup song all day, every day. Likewise I’m not savvy enough to deal with more than six people at once, so the meetings in a big organization wouldn’t do.

With arc90 I found a good balance. Sure, we still had meetings but never with more than six people, so I was within my capacity. And all the while I was surrounded with extremely bright people who really care about what they are doing. These guys (and gals) care. There’s a tangible energy around, so much so that I managed to do the impossible: get excited about insurance software. Yes, I didn’t think it was within the realm of reason either, but here I present to you a verifiable instance of this mythical affliction.

So after bringing out the boxing gloves over specification, Ben (the other intern) and I were let loose. Code was created. Diet coke was consumed. Yelling, well, happened. And yet, through all this programming in good times and bad, I kept wondering again: where do I fit in? I don’t mean in the organization, they had welcomed me with open arms and the accompanying intern-hazing, but rather as a developer in the grander scheme of things.

This is something I’ve always wrestled with. The normal analogies try to say we are scientists because of the degree to which we value quantification. Or that we are artists because we strive to create beauty in simple elegance. Or that we are architects because we scheme to create this beauty of elegance within a greater system, which in itself is beautifully elegant.

I’ve always thought maybe we were vanilla engineers, building the infrastructure and cool tools for the success of other disciplines. Or clowns, playing part in the grand comedy that’s life. This might be just me, but software makes me laugh pretty frequently, especially when I’ve written it and it sucks.

Kidding aside, architect used to be my favorite of the often-offered ideas. This was only magnified by my initial experience with our project. See, the specifications took a while to hash out for a variety of reasons, so before we had them in their entirety, Ben and I figured we’d create a gorgeous abstract system in which any of a variety of RESTful java applications could reside. It was tall, it was glassy. Maybe there was stainless steel, though I’ve always preferred aluminum.

Then as the specifications rolled in we just fit the pieces into this beautiful structure. We need a xeriscape garden on every floor. Check. Marble lobby. Check. Heated toilet-seats. Check. Our masterpiece was done. At the risk of running the metaphor dead, I’ll continue. Curiously, after we finished what we thought were the finishing touches, more contractors started showing up. The elevator guy wanted to install an elevator. “It’s not elegant, it’s not beautiful”, Ben and I implored, “It would cut up the xeriscape gardens in all the wrong places! What about their flow of energy?”.

There was a flash of realization. We had created something beautiful, sure. The framework we wrote was absolutely lovely, mostly due to Ben’s work; but when done it proved itself unsuitable in a lot of ways to the software we were actually building.

Around the time this was happening I found Stewart Brand’s series How Buildings Learn online. The first of six parts takes thirty minutes and talks about all the ways in which beautiful architecture has failed the people who actually end up using the building. He talks about how unfit MIT’s media lab (an I.M. Pei) is for it’s purpose– the exchange and cultivation of ideas. From this sort of soft failure he talks about more concrete failures such as the un-tinted, large windows at the French National Library ruins books with heat, and on the other hand how the tinted windows in the BBC building make it impossible to get sunlight considering London’s climate. Through all of this there was, in the back of my mind, the ghostly image of what Ben and I had built.

It was heartbreaking. Overall, I think we had done a great job, but there were key design decisions revolving around the use of Hibernate that just kept getting in the way. It was absurd to the point where when given additional specifications or even upon realizing the existence of preexisting specifications rather than simply implement them, we instead fought hard to bodge that functionality into the beautiful but unfit framework. On reflection I wish that we had the spot-courage to rip down what needed to be ripped down. The 100ft tall statue of Perilous, the great greek god of abstraction, in the lobby where elevators should have been, comes to mind.

In the end, we did pull it all together, but I’m still nagged. I’m a decent programmer, Ben’s a better one and it was still painful to build this system. Upon reflection I think it comes down to something not really talked about in the programming world: courage.

It’s not a crime to build beautiful systems, Elegance is a merit– not a flaw, and abstraction is a key tool to both; but one needs to realize that these are not total goals unto themselves. The creation of functional software fits in as well. If the world were perfect, and thus specifications perfect and upfront this would not be an issue, keen eyes and minds could combine programmatic aesthetics and functionality ahead of time. Shall we invoke the idea of an intelligent designer? However, specifications are incomplete and fluctuating; thus the systems we build to meet those specifications must be able to do so as well. Shall we invoke the idea of evolution? The issue is that software does not fluctuate. It can be built to meet a variety of needs, it can be flexible, but the flexibility is not absolute. That’s what we ran into. We couldn’t stick around without creating anything and wait for complete specification before doing what we do, so we made a call and wrote the software we thought would be flexible enough to meet any foreseen requirements in our domain.

Ultimately, we thought wrong, but instead of saying, “alright, this isn’t right.”, we said, “how can we force this unforeseen specification upon our lovely and elegant code-base”. When this process was over we had frankenstein. It was all backwards and jumbled, all buggy and unmaintainable. What we didn’t realize is that our framework wasn’t holy, didn’t have feelings, and wouldn’t press charges. We were afraid to hurt it. Instead, we should have ripped it apart. It wasn’t a black box, we wrote the damn thing, so why were we afraid to break it down to make it better? We simply didn’t have the courage.

It takes courage to destroy what you’ve created. Everyone’s got a bit of a god complex and wants what they’ve made to be perfect. Listen: even god wasn’t so lucky. You figure, though, that writers write and re-write to create the what best reflects their aim (I don’t, but I’m not such a great writer), why should programmers not do the same? If we had realized this and ripped the guts out of our prior work at an earlier time the whole experience would have been easier and more enjoyable. To a programmer, programming should be enjoyable, fighting with your own codebase gone-bad isn’t enjoyable. If you’re at that point make the codebase right. Then keep developing, not fighting. Have some courage.

When Brand asked one brick-and-mortar architect how he learned from past mistakes, he replied, “Oh, you never go back, it’s too discouraging”. Discouraging it is, but I’ve learned a lot.