Another vote for changing your blog name to “False Dichotomy Horror”.
I agree that in the end working software is what counts. That is one of the points that I am in full agreement with the Agile Manifesto http://agilemanifesto.org/ - to value working software over comprehensive documentation.
I have to disagree with one of the other commenters that you cannot compare government with private sector. Yes, the goals of these organizations are different - government is often trying (in theory) to maximize service for dollar spent rather maximize profit, but at a certain level you can compare the two - i.e. what is the development cost + ongoing maintenance cost to maintain an app with a certain number of function points. In my experience, the cost is much higher for government due in part to all the extra documentation and project rigor. Ironically, this extra bureaucracy is often justified in order to avoid wasting money, but in my opinion the cost exceeds the benefits.
Andrew,I agree with u,its the same which happens with Service based it indistries too…
Doing is extremely important – I agree with you there, Jeff – but it’s important to do something that is actually constructive and advances you toward your real goals. It’s all too easy to get fooled into doing something that you THINK will take you toward your goal, but that actually won’t.
“$16 million is being spent on a rail trail conversion study. That money would be enough to build a new freeway interchange and relieve millions in congestion delay and improved safety today.”
For how long?
Yeah, building roads works SOOO well to eliminate traffic congestion. That’s why L.A., which has the highest ratio of roads to people space of any city in the world, has no traffic jams, right? $16 million might build ONE freeway interchange – or the beginnings of a working rail transit system.
Another example: Implementing office automation instead of ONLY things that actually increased productivity cost billion$ in lost time and decreased productivity. Automation for the sake of automation often slows things down while requiring unnecessary work.
More about how to distinguish worthwhile targets for action here: http://managingwholes.com/good-goals.htm
Doers created Windows 98
Talkers created Vista
Choose your poison.
The last project that I was on at my last company went from being a dynamic and exciting environment, to a boring and frustrating one. That is, we started as RD and (d)evolved into a “program of record”. I am not sure precisely what that means, but to me it meant that the days of cranking out code and for demonstrations and POC were gone replaced with endless meetings, telecoferences, and Powerpoint. Now, I can’t say that the former was necessarily better than the latter because a lot of the bad stuff of the latter was due to the massive hackery that we performed in the former. However, endless meetings, collaboration sessions, and documentation CANNOT be the way to go. There must be some middle ground that can be met, and actually I believe that I have found just such a middle ground on my new project (with a new company). We are still able to crank out code (this time it’s actually used – go figure), but the documentation and collaboration requirements are more easily met using Web 2.0 methods: namely the wiki and blogging.
-m
thanks, worse-is-better, for teaching us that buggy code on day one is better than well-designed code a little later
By definition, everyone who posted is a talker and not a doer.
There is a difference between talkers who have done and those who haven’t. I’m called an IT architect. When asked if I can actually work on the code development I answer, “I could, but they don’t let me do that anymore.”
A definition of a Scottish Gentleman is “A Scot who can play the bagpipes, but doesn’t.”
It is worth some research planning the interfaces, data models, etc. up front so that they are adequately flexible, do not impede exploiting future technologies, and can have their implementations replaced later.
Well let’s see here, what’s on my list of things I’ve accomplished… well… hm… uh, consumed resources? I just sorta may be a talker right now…
Regarding the traffic construction .vs. study, how do you know construction will alleviate the traffic?
Isn’t that like saying “our servers are slow, we should Add More Code!”
as a quote from David Clark goes like: “We reject kings, presidents and voting. We believe in rough consensus and running code”.
[http://www.ietf.org/tao.html]
Doers allows a society to function.
Thinkers/Talkers makes a society progress.
Both are required.
Interesting article and comments. One goal of software development process to use the path of least resistance to achieve the end goal which is a piece of quality software. This path may involve both talking and doing at various phases. For example, you need to talk a lot when you start envisioning but should do less when you start writing code. Then you might start opening your mouth again when their is a problem or you need clarification. Or simply because you are not happy.
Too much discussion sometime can distract people from actual goal. So it is wise to keep communication small and to the point.
That said, I am doing too much talking already… 
- Indra
i’m a reader
Brian in Texas, you don’t really pay tax on fuel at all. Come to the UK and experience petrol at over 1 per litre. Yes, per litre. Diesel is even worse.
Ideally, planning and code-writing overlap and are conducted iteratively and successively over the course of a project, with the latter activity occupying roughly 70-80% of the developers’ time.
Upfront planning (and perhaps an initial architecture or design) most certainly doesn’t hurt - if anything, it’s good to know which direction you’re taking - but what’s important is to start transforming your thoughts, ideas and plans into working code (or at least a prototype, even if it’s a throwaway) as early as possible in the lifecycle.
I think it matters what people are talking -about-. As you said in one of your replies, Jeff, some people just talk to avoid work. If anyone thinks that all $6 million for the government bridge study is actually going to be spent on studying, then I’ve got my own bridge I’d like to sell them.
Mind you, the concepts of “talk”, “architecture”, and “design” are all being conflated here. Talk is requirements, and should take a couple of hours at most, maybe a couple of days for colossal projects. Architecture is, well, architecture. Most of the time, when you see people overarchitecting, it’s because they’re unconsciously reinventing Microsoft Access or something else that already exists. Design is thinking through the individual classes and interfaces and knowing what they’re supposed to do and how they’re supposed to connect, rather than blindly hacking away at it.
All of these things are important, and all of these things CAN be abused in order to avoid doing actual work. Writing the code is, by definition, doing the actual work - however, people who dive into the code and refuse to waste any time on higher-level abstractions also love this as an excuse to avoid doing the work that they don’t want to do.
Doing the actual work, but doing it completely wrong, is not much better than doing nothing. Worse, if somebody’s paying you by the hour. Catastrophic, in fact, where safety is a factor. A lot of developers don’t work on safety-critical applications, and that’s fine, but I don’t think those people realize just how much up-front planning goes into something like a bridge or a skyscraper. You don’t just start slapping bricks together!
The question that this post doesn’t address is: where does that leave bloggers? Or those who read and comment on blogs?
I am a hacker style doer. I usually end up writing the foundation of something, only to tear it up later and re-write the whole thing because the earlier foundation can’t support when I discover I wanted it to do during development. Its a wasteful practice, but in the end I produce an excellent product that does more and is better than what my initial vision was. It is however, still a lengthy process to write a prototype, only to trash it halfway through development.