Coding Horror: It Came From Planet Architecture

December 27, 2004

It Came From Planet Architecture

Coming from humble Visual Basic 3.0 beginnings, by way of AmigaBasic, AppleSoft Basic, and Coleco Adam SmartBasic, I didn't get a lot of exposure to formal programming practice.

One of the primary benefits of .NET is that it brings VB programmers into the fold-- we're now real programmers writing in a real language, using the same IDE as the C# and C++ guys. And like other real programmers, we are expected to use proper development patterns and practices, many of which were absorbed from the Java world. It's a great opportunity for the masses of VB.NET developers to improve their skills and become more productive. However, there is a dark, non-productive side to the patterns and practices brigade: something Joel Spolsky calls architecture astronauts.

an astronaut

It's a phenomenon I strongly associate with the Java world:

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
These are the people I call Architecture Astronauts. It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture. They're astronauts because they are above the oxygen level, I don't know how they're breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don't contribute to the bottom line.

Here's the key distinction between an architecture astronaut and a practical developer: when you're in the trenches proving your ideas by implementing them in real applications. The kind used by actual users. Christopher Baus articulates this best in doers vs. talkers:

Software isn't about methodologies, languages, or even operating systems. It is about working applications. At Adobe I would have learned the art of building massive applications that generate millions of dollars in revenue. Sure, PostScript wasn't the sexiest application, and it was written in old school C, but it performed a significant and useful task that thousands (if not millions) of people relied on to do their job. There could hardly be a better place to learn the skills of building commercial applications, no matter the tools that were employed at the time. I did learn an important lesson at ObjectSpace. A UML diagram can't push 500 pages per minute through a RIP.
There are two types of people in this industry. Talkers and Doers. ObjectSpace was a company of talkers. Adobe is a company of doers. Adobe took in $430 million in revenue last quarter. ObjectSpace is long bankrupt.

Patterns and practices are certainly good things, but they should always be framed in the context of a problem you're solving for the users. Don't succumb to the dark side.

Posted by Jeff Atwood View blog reactions

« Reducing Useless Clutter on Websites Spurious Pundit »

Comments

Jeff,

Thanks for the link. I'm glad to see people are reading this article. This is one of my fundamental philosophies of software. While process may help software, process is not software. It is easy to forget this, while focusing solely on the process.

If you ever discover that your process is preventing you from shipping software, it is time to change your process.

Christopher Baus on December 28, 2004 03:18 PM

"Learning consists in adding to one's stock day by day. The practice of Tao consists in subtracting day by day: subtracting and yet again subtracting until one has reached inactivity."
-Lao Tzu

sam on December 28, 2004 03:59 PM

God! I love this blog! LOL. You don't know how many articles on here describe my workplace to a tee. I'm having Dilbert Principle epiphanies in Machiavellian office politics.

Gene Mangrum on December 28, 2004 07:22 PM

I'm glad to see others with this same philosophy. I was starting to feel like I was the only one left on the planet that thought that software development was starting to move into some type of etherial, intangible "lost art" type of status. This is one of the rare cases where the journey is LESS important than the destination.

I even proposed a new acronym on my web site that would attempt to exclude everything but the key object oriented concepts. I called it SOOP (or Simple Object Orented Programming). It was my last, futile attempt at holding on to an era when software was designed, developed, and shipped within months.

If you are wondering, I've just spent a whole month forced to work on a project that is rougly a year behind schedule, and has produced almost no usable code. And, it is our 3rd or 4th (can't even remember) attempt at producing a new client application at my company.

Sigh.... I feel like I'm in a support group for lost productivity developers. Hi, my name is Josh, and I'm a lost productivity developer.

- Joshua

Joshua Bair on December 31, 2004 04:02 PM

Wow, Josh. That's a pathological case. I see tendencies towards this where I work, but nothing that severe!

In a case like that you might try referring to McConnell's Rapid Development; he has some chapters on how to recover derailed projects.

Jeff Atwood on January 1, 2005 02:07 AM

Heh. That's okay. The problem has pretty much taken care of itself. For 2005, the project has been budget-reduced and de-scoped nearly out of existance. But thanks anyway.

- Joshua

Joshua Bair on January 1, 2005 01:29 PM

Many years ago I worked for a company that basically died of this disease, so I know exactly how this works. J2EE encourages this type of programming. My advice would be:

If your company has less than 500 employees, do not use J2EE. J2EE is for writing *huge* enterprise apps for very large companies to be maintained by hordes of programmers over long periods of time. That's what it's for.

If you are a small company, use Ruby, Python, or something like that.

Adam Ierymenko on March 6, 2007 05:24 AM

The Agile way is my new hope for the future...Crystal

It was this Podcast with Alistair Cockburn that really woke my hope again.

<a href="http://agiletoolkit.libsyn.com/index.php?post_id=170374">http://agiletoolkit.libsyn.com/index.php?post_id=170374</a>;

Here is an earlier one...

<a href="http://www.vicasting.com/cast.aspx/iid/143541/">http://www.vicasting.com/cast.aspx/iid/143541/</a>;

Edward on March 6, 2007 07:17 AM

Ok, I can see your point, but I used to maintain a retail accounting system that first was written by a DOER (or so he thought), with no rhyme or reason to how he did something, his code was DONE all over the place, it was a nightmare to code to. The only reason it sold, it was cheap, barely got the job done, and had source code with it so you could fix whatever was broke, this was circa 1985+.

Their next version was written also by a DOER but with a little more Astronaut in him, and his code has reason, patterns, similarities, etc that made it so much better to code to, sold more, had more extensions (cause you could count on a pattern being there).

As for your philosophy of 'I code therefore I am' is WAY OFF. If you're any good at what you do, assuming you are, its because you're smart, not cause you've spent tons of time typing in programs.

I'm one of those "Formally trained software architects" and can tell you that those who are formally trained typically turn out better code than those who aren't. I think you would agree, just cause you can code, doesn't mean you should.

I have great respect for the guys who can come up with the high flying patterns, but even more respect for those that can implement them using 1/2 the code others do. ORM's come to mind here, how many VB programmers scoffed at ORM's in JAVA and other languages, only now to embrace in .NET?

Good Blog!

John M on July 23, 2007 03:45 PM

Hi Josh.

My name is Brian, and I'm a lost productivity developer. I was hired because of my TDD background to help fix an already late project. I proceeded to test a system that was no where near fufilling it's requirements. There was no issue tracking system, I was the issue tracking system. Two months into employment i noticed i spent more time creating spreadsheets and sitting in meetings describing our poor progress, then contributing to said progress. I also realized fairly quick that the developers at the company, many years my senior, new very little of the actual requirements and .net. After four months of grueling work and weekend appearences. I was told "Well thats the last time we get a developer to do a QA job" by my boss upon completion of the task.

Brian on July 23, 2007 07:15 PM

We have some code here that has something called a GlobalThingServer. Templated of course, and when instantiated is often used with his own smart pointer class which derives from a ObjectReference class which derives from a ReferenceCountedObject class. Sometimes.... I just feel like giving up... :'(

Bobo The Sperm Whale on May 6, 2008 07:48 AM