Jeff,
I just started reading your blogs recently. All your blogs have been informative and refreshing in their insights.
Here’s wishing for more gems from you.
Thanks.
Jeff,
When the problem domain is trivial, like StackOverflow, your blog post makes much more sense.
The implementation may not be trivial (thinking of stack overflow again) - I would not call any code base trivial - but it is quite a different story when the business model is significant. Just what are you going to sit down and code ?
In other words, we all know what a shed is. We all know how to paint. And we all know what colors are. So instead of talking about it too much, let’s paint the darn shed.
There are many software systems where the software engineers do not know the problem domain they are coding, so they cannot sit down and code. For example, implement a control system for an automatic transmission to be embeeded in an automobile’s computer. We better talk before we start typing.
The bikeshed effect is not about abstractions, but about trivialities. An architectural astronaut would not be debating the shedís color; heíd be trying to come up with a scheme that would allow the shed to be any color the client wanted.
Not exactly. A normal person would come up with this, because it’s a pretty obvious requirement. Client needs blue shed, so it’s within the realm of reason that they might want a red shed, and it’s cheap, so why not? Most of us can handle that.
The architectural astronaut, on the other hand, would decide that color just isn’t enough. Maybe, in some alternate reality, the client also wants methods to choose different types and style of shed. Maybe the client wants completely different dimensions, a few windows, a different type of roof, different options for siding material, etc.
But wow, all of this customization is a pain, and gee we have to do a lot of work just to make one lousy shed. So why stop there?! Maybe, god forbid, the client wants a shed factory that can produce any type of shed to meet any imaginable purpose ranging from rusty box in the back yard to an airplane hanger. And if it’s going to produce sheds, well shit, let’s have this thing make houses, condominiums, skyscrapers, duplexes, big-box retail stores, restaurants, malls, EVEN OTHER FACTORIES, etc. After all, they’re all just BUILDINGS, right? Why not abstract it out and have some general purpose Structure Factory? Instead of making sheds, we could make ANY BUILDING WE WANT. WHOOPEE!!
And let’s not make it closed: let’s expose OTHER METHODS for people to use this tool to fabricate types of buildings we’ve never even imagined; we’ll allow someone to introduce THEIR OWN MODELS into the factory and produce entirely new buildings without us having to do anything! Brilliant!!!1
So, after the client requested something that would take any normal person half an hour at most, the AA manages to provide complexity, abstraction, some massive hairball of code (presumably vomiting OOP like it’s 1994 and we all collectively forgot about the pitfalls of using a hammer to pound screws), well past schedule, etc., all of the AA’s coworkers decided to kill him and hide his body in the woods.
Someone went out, spent twenty bucks and two hours of time to paint the shed blue, and everyone was happy.
Lepto Spirosis: If you don’t go to meetings, ignore phone calls, and archive all unsolicited email until the end of your project, you might get some useful work done. Otherwise, there seems little chance.
You might also miss the news that your project has been axed, half the dev team have been fired, and even without all that, the fact that your implementation of the business process bears very little resemblance to what happens on the factory floor.
If you are the designer of both process and product, by all means go and do your own thing. Otherwise as Bill says, we better talk.
Alastair -
Exactly. I want our people exerting maximum effort on the project at hand. They are paid a boatload of money. I expect nothing less than very good code.
- Lepto
— There are many software systems where the software engineers do not know the problem domain they are coding, so they cannot sit down and code. For example, implement a control system for an automatic transmission to be embeeded in an automobile’s computer. We better talk before we start typing. —
Bill,
I somewhat agree. But there’s a not-so-fine line between We better talk before we start typing and It’s been nine months, and we’re STILL talking…
And a lot of times, I think the obstacle is the Architecture Astronaut; the programmer who is utterly obsessed with the details, wants to use the latest buzzword w/r/t software development and apply it to every facet of the project, adds new functionality in an almost whimsical manner, is prone to crafting concepts nobody else fully understands and don’t really contribute to the bottom line, etc. Combine that with the fact that most Architecture Astronauts are people who don’t fear technical jargon and are often painfully detail oriented, mix with three parts business suit and two parts marketing doink, and you have a recipe for total and complete disaster.
When projects with really complicated requirements are combined with people who are incapable of breaking down gigantic problems into manageable ones (and let’s be honest with ourselves: as programmers, a lot of us absolutely blow at this; I know this because I’ve had a front-row seat for about a year now), and you end up with complete and utter paralysis. Every meeting degrades into this high-picture overview of a monolithic system that is like staring at the sun.
I know this because it is my current life, and I work on a project that is incredibly complicated, and our biggest obstacle is these AA types. I’m literally watching a train crash in fantastically slow motion. If the world rewarded UML, architecture proposals and requirements documents, we’d be filthy stinking rich. But that’s not how things work.
… the amount of discussion on a software feature is inversely proportional to its value.
Isn’t this architecture by democracy though?
By simply picking an architecture that everyone accepts sans comment you’re bound to be choosing some worst of breed thing that any hack is familiar with. While this may seem productive in that any hack is prepared to code to it as well, it may completely ignore scalability, flexibility, longevity, maintainability, etc.
If this were really the goal everything would be a rat’s nest of flat PHP/MySQL web apps, damn the customer requirements or business realities.
I used to suffer from Apathy, but now I can’t be bothered.
a href=http://www.instantrimshot.comhttp://www.instantrimshot.com/a
ooh, URL got mangled there… where was that post on URL parsing?
Amen to that Jeff…seems like the comments have become a bikeshed discussion though! 
With regards to your comment about developers who are more interested in discussion than writing code. I find it interesting when I look at the SO site and see how many reputation points are awarded to people who ask questions like What is your favorite developer comic strip?
@ Mecki
Sitting down and coding can be fail too. On many accounts it is worth justifying what features go into the system as opposed to just blithely implementing anything that gets near to you.
I’m a big fan of reducing the number of possibilities because that reduces the complexity of the system and hence reduces the number of potential bugs.
Not only do you have to code the feature but you then have to maintain, support and possibly rewrite that feature (when refactoring / porting etc). Is the feature worth all that?
The reason we spend time in meetings is creating software is about satisfying customers, not writing code. If a feature isn’t going to satisfy the customer then coding it is negative productivity because of maintenance and support.
Exactly!, why am reading this blog when I have things to do!
+1 Eric Go back and read the post on ‘technical debt’…
skipping a little forethought is one of the shortcuts that results in debt.
Forget thinking critically, let’s all just start throwing stuff at the wall and check to see what sticks…
That’s just mental laziness and you end up doing MAJOR refactoring and re-designing, taking up lots of time that could have (at least mostly) been avoided initially.
This comment is probably the most insipid one in the thread, but the cover of the book looks really cool.
Some of my best and most lasting (read stable, useful and never fundamentally altered) accomplishments in this job were a result of month-long belabored discussions with all parties involved. Of course, the difference was that I came into the discussions with a detailed design complete with the implemented code right in the documents. The discussions revolved around specifics and tweaks which were quite easy to adapt to.
Also, some of my worst failures were around things I spent no time discussing with anybody and just implemented and checked in. We’re fixing that sort of thing now.
Additionally, I’m also currently spending a tremendous amount of time redoing things that others spent a month discussing in the abstract, and then somebody implemented it and checked it in.
Is this another dead tree (doesn’t that phrase become boring to you?) book that you haven’t read and this post mixed in with too much psychobabble junk science?
The bikeshed effect is not about abstractions, but about trivialities. An architectural astronaut would not be debating the shedís color; heíd be trying to come up with a scheme that would allow the shed to be any color the client wanted.
This neatly encapsulates the silliness of Architecture Astronauting.
6 months of arguing whether you can handle spots and stripes at the same time, and you’ll be beaten someone who just kept selling blue sheds. And then offered their customers some red paint.
Jeff,
No.
You totally take the focus off of how to pitch a great idea and simultaneously squash the bikeshed project’s consumed time.
So how do you push a good idea through?
DESCRIBE THE PROBLEM, THEN STATE YOUR CONTRIBUTIONS. Have a bulleted list of contributions. Do not make anyone guess what your contributions are, and show how well your contributions solve the problem.
Rather than diving in coding, practice getting ideas through FAST. The best way to practice this is EXPERIMENTATION AND PROTOTYPING. Challenge yourself with an idea, no matter how silly. A mini-research problem. Write down the problem, and how you plan to solve it.
Experimentation and Prototyping, followed up by practicing your elevator pitch, is the only way to train yourself to become really good at blowing past the foot draggers and empire builders.
And practice your elevator pitch at the water cooler, to one person at a time, until at least three people are on board with you. Then when you pitch it at a meeting, you hopefully already have a silent majority. Then you just have to squash the minority who want to talk about bikesheds.