I'm definitely a doer, to a fault. I don't plan enough ahead for things to come out as well as they should. But at the same time, the one major success I have had would have been lost had I not just dove in. So I'll stick with it and see if I can be a slightly more deliberate doer.

I'm a thinker. I think through and plan what to do well in advance. I do not rush. Where does that place me? I do not believe in dichotomies, in fact, they are convenient, attractive, suggestive, and the cause of most of humankind's evil.

There's a reason why governments are required to do studies: if they make a decision that turns out badly, they'll be held accountable at the next election. On average this means huge waste, but in each individual instance a study that says "do nothing" costs less than the highest estimated potential cost of a failure. And there's always plenty of expensive failrues to point at and claim that an additional study would have prevented the problem.

Waste six million dollars on a study for a bridge that will never be built or risk building a bridge that you can't offer a 105.35% chance of having no accidents until after you're dead and buried and can't be held accountable. Go on, you choose.

And despite the miracle of private enterprise, when you have 83 levels of vice-presidents between the guy doing the work and the guy who owns the money used to pay the guy doing the work, you'll find most people will value appearing to save the owner's money over risking something that might make the owner some more money.

"Doing" is important.

"Talking" is safe.

Put your job on the line when success means the owner gets a new porsche (and you get the promise of a 2% raise at the next leap-year review) and failure means you get fired (but the senior VP in charge of product planning coordination still gets his annual bonus for elimination of unproductive works who do stuff instead of planning) and then you'll understand why safety is a popular choice.

I'm not saying that talking is better than doing - just explaining why the 80% of programmers who never read blogs are going to keep on putting their own personal interests ahead of, for example, actually producing working code.

For that matter, I bet it's not a coincidence - the people who don't care about getting actual products into the hands of actual users have nothing to gain from learning ways to do that. But if they get a job at an I-Bank instead of a Web 2.0 startup, the ability to play the meetings-and-planning-and-talking-and-UML-and-so-on game can keep them safe for a long time.

Me? I'm a talker. All bluster and eyebrows, and precious little code.

... Buahaha!

More than that, writing actual code is often a way to "win" the endless architecture debate.

The KDE project has a saying: "the one who does the work decides". As with any major project, there's a lot of discussion going on - but while some people discuss endlessly, others produce working software, artwork and documentation. This seems to work quite well.

It depends.

If we stick at software, I'd say that for personal projects and interesting ones, I like the "Doer" part. For the same ugly, complex systems that happens at most of the in-house software producing companies, I'd rather choose the "Talker" role.

As Jeff says, being somewhere in the middle (or rather more to the "Doer") should in theory allow to build working and nicely designed software. But in todays industry that is not required. The uglier the code the more you can bill for it later as support and maintenance. The more time you spend designing it and showing flashy presentation to the stakeholders the more budget the project gets. In industry, do a lot talking and then hack together something fast.

This is different with open source and for companies that rely on few products. For them quality is essential. Either because money is not really a factor or because the money comes from the quality. But, they can never stop at building the core of their software, while in-house programming can support a company for years or decades without really adding anything new.

Also, don't build a bridge without proper study. It might be a good example for physics students as it happened before, but don't forget that people will cross over it. Or at least try to.

I don't mind planning, but the architecture has to be reasonably minimal. The infinitely scalable software is really a pipe dream that's effectively impossible to make, so at some point you have to make something.

What I often tell clients with big ideas is actually pretty simple: we'll start small and then grow as needed. If your project "goes big", then we'll have enough money coming in to re-invest in scaling out the solution. Like you said everything works for small N, but complexity increases exponentially for bigger N.

If a project goes big enough, at some point everything on it may well be re-written, but don't worry, this is a sign of success, not failure. I'm working on one such project that's gone from 0 to 25 million in 6 months, but the only reason this worked is b/c we were first to market. Since then we've touched almost every query, but at least that work is now being paid for.

Neither...I'm a reader. Doh.

Don't forget the I-35 bridge collapse this past August.
http://en.wikipedia.org/wiki/I-35W_Mississippi_River_Bridge

There is definitely needs to be a healthy relationship between planning and doing.

Talking is only important insomuch as it is focused on the doing.

Now if only we could do both.

'And God said, "Let there be ...," and there was...'

Now thats a supreme coder!

"Since then we've touched almost every query, but at least that work is now being paid for."

I would like to engrave this on people's heads: architecture that isn't providing real value today or in the *very* near future is nothing but an expense, and expenses without return in some reasonable period is waste.

Sure, I would love to live in some ivory tower and insist that every solution be extensible in nine ways without code impact and be scalable from no users to every living person on the planet... but if it is going to prevent the realization of ROI for so long that the company will be out of cash (but have really pretty diagrams to hang on their walls whilst looking for their new jobs) then something has to give.

This is not to say that architecture should be *ignored*. It is to say that when the conversation today sounds like yesterday's and the day before, it is time to move past theory and into practice.

> It is to say that when the conversation today sounds like yesterday's and the day before, it is time to move past theory and into practice.

Agreed. It's all about self-awareness. Communication and discussion are good things, but like all good things they can be taken too far. When you find yourself (or your team) slipping into this trap, invoke the "less talk, more code" rule.

Sooner or later you have to show something for the money. Something tangible. And I don't mean a lot a bull crap about how to implement the project using SDLC and feasibility studies.
Sure, the user specs, system analysis, UML and design documentation are all very useful tools in their proper context however, none of that can replace a good ole 'down and dirty' coder or; as we used to call ourselves in the early 80's before the press defamed the name, hacker.
There is something to be said about the planning however, it will never replace the master builder, like the guy who built the great pyramids or the roman coliseum or Andy Herzfeld, Woz, even Billy himself.
You get great products from great people, mediocre products from mediocre people and as far as I can tell, nothing from talkers.

Analysis paralysis

Too much of that going on

"You get great products from great people, mediocre products from mediocre people and as far as I can tell, nothing from talkers."

Good quote, but I belive talkers do deliver something, a large bill for their time.

It was hard to get past the first paragraph. Here in Texas we pay a crap load of tax on every gallon of gas that goes into the Highway Fund. It raises around 15 billion a year. Problem is the lawmakers like to raid that fund every year for other stuff so now we do not have enough money to build highways and we are now getting nothing but toll roads in the Austin Area. heavy sigh.

Oh yes, I am better at doing and get very frustrated by talkers.

Personally, I'm frustrated by doers and cheap cop outs like "analysis paralysis". We had one manager that cried analysis paralysis anytime someone questioned a requirement - absolutely ridiculous mindset. Talking up front is essential to do something that is worth doing. Yes, if you just dive in and do you will likely get something but virtually never what was intended, never on time, never on budget and always with an excess of bugs.

Count me as a talker who describes what to build first and then builds it once the goal is clear. When going on a vacation, you don't hop into your car and say let's go. You plan where you are going so you know what to pack, which direction to turn once you leave your driveway, which highway to take, etc. Too often in software, "doing the job" is used as a euphemism for grabbing some of the family (but maybe not all - to stop and check if we brought the baby would be too much planning) and jumping into the car and peeling out of the driveway. Hardly an effective way to have a good vacation (not to mention the eventual legal issues for child abandonment/endangerment which are an excellent euphemism for the eventual lawsuits for buggy software that doesn't meet the requirements clearly laid out in the contract of sale).

I can be both... thinking of a problem for days... or being a doer so much that I use...

*looks behind shoulders*

(gotos in my C# code because they are faster than restructuring my loops)

*runs away*

Personally, I tend to talk a bit, then start doing, then lose interest when I'm halfway done. Not sure where that leaves me. ;)

Let's assume that everyone did their homework on XP, RUP, Scott Ambler's agile development, component and model based models, etc. Let's also assume that everyone agrees that some kind of initial artifacts are required for a software.

My question would be: why do projects still fail at an alarmingly huge number? Is it because neither the client nor the developers have the proper envisioning, do they slack of or still go into the ivory tower? Are the requirements or estimates that off?

My answer is that probably my assumptions are bad. I don't think they are true in most of the cases. Referring to those as the aforementioned 80%, isn't there a need for personal advancement?

Just some thoughts, go on with the discussion of the different "styles" of software development...

Also,
> Yes, if you just dive in and do you will likely get something but virtually never what was intended, never on time, never on budget and always with an excess of bugs.

Normally everyone does (or should do) some planning. Even if we talk about extreme programming there is planning going on right under their nose. That is something that must be done if
a) more that one person uses the code
b) if it's a bit more complicated system then a Hello Word! program.

The feedback from going to code is invaluable. It doesn't mean you don't stop and think and talk some. But the main feedback artifact is code in some state or working or not.

The timing of your post is ironic. I was just complaining about design heavy practices at my place of employment.

"My question would be: why do projects still fail at an alarmingly huge number?"

Is that really the case though? Are that many projects actually failing?

http://thedailywtf.com/Articles/Illicit-Process-Improvement.aspx

This guy got in trouble for developing a great application in his own time, while the corporation was still TALKING about it (and building a shiny new HQ). They went out of business a few years later.

You've touched my heart. Many business decissions are made by people who talks. How many times some stock options have risen or fallen simply because somebody has talked?

Yes, we prefer coding *and* talking, at different but similar ratios. But up there, in the next hierarchical level of your office, there can be someone who doesn't know about coding, but needs to assign a value to your product. What can (s)he do? He will measure your words, even your charisma, even your dress! He will measure the kind of tools you use, if they are the state of the art or not, or their market price, he will measure exact parameters as time, lines of code, etc.
Sometimes this is useful, perhaps in complex projects, but Charles Miller seems to have suffered the experience: There can be "sorts of damaging debates". There are projects that reach their goals only when you leave them alone. If you are having fun coding to reach your goal, and your brain is in that lovely productive state, then a bad criticism in the bad moment from someone who only tries to demonstrate that he can do better than you, or says "You have no idea of what you are doing", can demolish the work.

(Sadly, I've sometimes read phrases like last one in this blog too -not from Jeff, but from commenters)
I think that constructive people doesn't need to demolish other's efforts with aggressive talking, they simple *add* their knowledge to the project. Unless there are lots of money around, or fame, etc... In that case, the always-in-war human state, the winner takes it all.

> Is that really the case though? Are that many projects actually failing?

By failing I mean project not done in time, going over the budget, not meeting their requirements ergo not successful.

"In this new millennium, it is still true that approximately 29% of all large-scale systems projects are successful, 53% are challenged (with average overruns of 84% in time, 56% in dollars and only providing 67% of the required functionality), and 18% are scrapped and written off altogether. Although these stats show a small improvement over the statistics from a decade ago, and even with all the reported advances in technology, methodology, and software development and implementation, this is a poor showing for the Information Technology Industry [Source: Standish Group “Chaos Reports”]."
-- http://www.hgexperts.com/hg/legalarticle-software-projects.asp

Even if we say that these statistics are highly overrated my real life encounters are proving this on a smaller scale. Not saying that you should believe these numbers, but even if consider 60% being challenged I would still call that bad enough.

>Agreed. It's all about self-awareness. Communication and discussion
>are good things, but like all good things they can be taken too far.
>When you find yourself (or your team) slipping into this trap, invoke
>the "less talk, more code" rule.

The typical course of most software projects: endless discussion by users and development managers without achieving any awareness of the actual needs that prompted the project. Followed by heated architecture arguments by developers who couldn't cross a street without causing a major accident. Concluded by said development managers rushing into the room to shout, "We have to get this thing done!" (and of course the rumbling feet and clattering fingers preceding the code that would fail to make a million monkeys proud.)

In all the talking that goes on most people forget to think.

> In all the talking that goes on most people forget to think.

It's even worse when it's true with the clattering fingers.

>I'm definitely a doer, to a fault. I don't plan enough ahead for things to come out as well as they should.

i'm also in that group.i also do not spend enough time to plan the project i'm working on .heck ,sometimes i don't even make pseudo code.

My wife is a talker. I'm a doer. It makes for very difficult communications! All of the dip head managers that I've ever had were talkers. The good ones were doers.

> Working code attracts people who want to code. Design documents attract people who want to talk about coding.

Non-working code requires documentation or no one will want to join the project and work on it.

"There are two types of people in the world: those who divide the world into two types of people, and those who don't."

I submitted it to Digg and reddit, i thought it was that good.

http://digg.com/programming/Coding_Horror_Are_You_a_Doer_or_a_Talker
http://reddit.com/info/62rbc/comments/

Just thought i would give you a heads up, and oh.. i hope you enjoyed my caption. :)

"There are two types of people in the world: those who think in black and white, and those who don't"
-- Me.

This is almost as boring of a generalization as the 80/20% programmers. Was there actual insight in this post I missed?

There's a time for action and a time for planning; both are important. People can be good at both, and can learn to be good at both.

Perhaps the folks at Microsoft should have done more talking before they produced the atrocity known as SharePoint?

> People can be good at both, and can learn to be good at both.

Some people on software development teams are *unusually* good at habitually avoiding action in favor of excessive planning and discussion. It's a bit endemic to the profession.

A specific example-- the details are not really worth going into, but those in the community ( http://www.chadmyers.com/Blog/archive/2007/12/10/dear-alt.net.aspx ) will know what I'm referring to-- is what prompted this post. So it's fairly topical, at least from my vantage point.

Hey Now Jeff,
Both is a good way to be with an more doer. When building a dog house ( http://www.codinghorror.com/blog/archives/000960.html ) I like to just be a doer & learn by the mistakes I make. On a skyscraper there has to be more planning. You made a good point made by this post
Coding Horror Fan,
Catto

Be a 'Doer,' but prepare to throw one away. I've always thought that was the greatest insight of Fred Brooks, at least from a developer's viewpoint. Some people only think intelligently after they've tried to do it once. If nothing else, it keeps your architecture within the realm of the feasible. Case in point: I worked for a company that was planning on deploying a distributed database over a wide geographical area, and the architectural astronauts assumed that it would be easy to merge two database change sets into a consistent whole.

Just make sure your first code blast is butt-ugly or you'll be forced to ship the prototype, and all developers that come after you will curse your name in perpetuity. Green-on-yellow web pages with a serif font works for me.

It's so much easier to talk. Every time I try to implement any of my ideas they always end up coming out not as I expected.

And even when they do I'm still not happy! But saying that, if I went through a couple more iterations of prototyping I'd probably get to where I intended, but it's oh so much work! (I'm talking about open source libraries I plan on releasing).

Ze Frank has a humorous video on this subject, ideas vs implementations:

http://www.zefrank.com/theshow/archives/2006/07/071106.html

Enjoy!

There are 10 types of people in this world.
Those who understand binary, and those who don't.

Ever tried to maintain software that was all doing and no talking? Might as well throw it away and start over.

I'd also say there's another type of person--the person who can look at a problem and instantly know the proper solution whether it's in their field of expertise or not--like a bridge across a lake on the other side of the country. Engineers are particularly good at this until someone's life depends on their design and then they want to do a study first.

Mike

"Talk is cheap!" "Analysis paralysis!" "Meetings are always a waste of my time!"

Yeah, wake up and smell the coffee, road apples. And welcome to something else than the 80's. Software development has evolved since, believe it or not.

Going up in CMM levels is a good thing. Organizations at level x deliver more often on time and with less bugs than organizations at level x - 1. Don't waste your time arguing, it's a demonstrated fact.

But what does it take to go up a CMM level? More talk. More communication. More tracking. More Excel sheets. More spider graphs. More talk.

Here's an excerpt of description of a CMM Level 1 (from Wikipedia):

"Success in these organizations depends on the competence and heroics of the people in the organization, and not on the use of proven processes."

I see this as meaning: "Success depends on the chronic doers." Unfortunately, the software development industry at large still believes that's the way projects work. Utter three words in the champion's ear and let him slave at it over the next month. Whatever...

Chronic doers are usually seen as less harmful than chronic talkers -and I surmise that has to do with the fact that worldwide coding community is in majority male- but in my opinion, they are just as harmful.

Unfortunately, I used to work at a company where the boss and his lieutenant, the so-called architect, always think that doers are nothing more than hackers. The architect loves to document, which is not bad idea, but that's all he can do, and he can only do it at 300000 ft level.

I'm a doer. In fact it occasionally gets me into trouble. I really do believe that prototyping is needed unless you want to end up with shitty software that barely works.
For relatively small subparts of systems, say 1000 lines or so, it might take a couple days to design it out in enough detail so someone else can implement it badly over the course of a couple weeks. On the other hand, a skilled engineer might only need another couple of days to produce a reasonable implementation in addition to the documentation.
These numbers might seem pretty crazy but it's nothing out of the ordinary in some companies. 10:1 factor baby!!

I am a doer. My mentor always told me - "The first thing is to always get something working." When you think about it, let's say someone hires you to build a website. Noone wants to here about all this great design patterns crap and UML diagrams, and then see no coded software behind it. They want to see code in action.

In my 12 years, I have seen a lot of talkers. They all had one thing in common, they got fired.

Just to clarify my comment above. By "Talk", I really obviously mean "Recorded communications", not "Use your mouth to say words in the air".

And taken to extremes, a process of purely talking (as per my definition) and a process of purely doing can both end up useful, useless or harmful. What people seem to think, which irks me to no end, is that a process of purely talking can *never* be useful and a process of purely doing can *never* be harmful. That's what I have a problem with.

I'm a doer. And being a doer, I've done hundreds of projects. I will be the first to admit that most of my projects fail, or don't even get finished. Many of them are also just one time things (eg. I need to do such-and-such process to solve a lot of problems today, so I make a program that does JUST that). However, I'm also a redoer! When a project of mine shows promise, or gains support, I do it all over again. I examine the project, looking the good, the bad, and the ugly. Rethink most of it, and make it great, brilliant, and beautiful. That, I think, is the most important reason why I have any success at all while still being a doer.

I'm considering moving into research / teaching.

That way I can be a full time "talker" in the programming field :)

This is precisely what I'm suffering from at the moment (well for the past few months). I've been reading a lot about the new .NET 3.5 framework, C# 3.0, MVC platform, but I have hardly done any actual coding. So, I'm a reader/talker and not a doer. I probably know more about these .NET technologies than those who are coding but I have practically nothing to show for it.

2008, a time to change.

> (gotos in my C# code because they are faster than restructuring my loops)

@KTamas: this is the thing for you: http://xkcd.com/292/

i'm a reader :)

The more I read this blog, the more I see posts like this:
"You should think of this aspect, it is improtant. But surely, other aspects are also important."
For me, such posts don't have any value.

Current software is bad. If working code is so important, why there are many clones of same class apps and they all are bad?
"Start code, start open source".
Yeah, I started. But when I wrote a big chunk (almost finished) of it I realized it have complex parts and bugs that are above my abilities to track and solve. So, maybe I better think first next time and make better design/do something simplier.

On the whole I'm probably more a talker/reader than a doer, which is OK, as I'm not a professional programmer (far from it). The few times I 'have to' code for my work it's often very short and simple stuff. However, the biggest programming project I ever did came out of a frustration with too much talking and also showed me the benefit of actually getting something to work. Part of the problem was that the specifications where highly unclear (think small research related software), partly by design (it was supposed to 'evolve'). However, we spent months talking about what we want to, should and could do without ever getting anywhere. It was exactly what has been described above - we kept talking about the same 'what ifs'. Time was running out, and I simply took over the coding process (it didn't help that our main/single software engineer no longer lived and worked in the same geographical area), and started to get stuff working. Of course it was a pain to later bugfix and change things, and in retrospect I probably should have done some things differently, but at least we had something we could work with.

"You cannot plough a field by turning the soil over in your mind" - anon

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.

One major point is most of us write software for private companies who have to think about the money they spend. You cant not compare goverment agencies/Public sector with real work. The amount of money government agencies hemorage on doing nothing is really quite amazing.

A doer I guess.
High level architectural talks are lost on me sometimes if they can't really contribute to anything practical and down to earth.
At some point it just becomes too abstract to see the point of it all.

You hit the nail on the head when it comes to the Open Source projects.

If there's one thing I hate it's finding this l33t looking SourceForge project which doesn't have a single line of code in the repository and is still in the "planning phase" when you look at it in detail.
I want working code dammit! :)

Think...Code it...Find Faults...Think...Code it...Find Faults...Think...Code it...Find Faults...

Excellent insight and a great article. One of my biggest sources of frustration is dealing with self-annointed "gurus" who talk a big talk about architectures and methods and other obscure and bizarre ways of doing things in software applications. And when it comes right down to getting an answer to the question: "yea, but why would you want to do it that way??" the answer is invariably: no reason, except maybe add another layer of complexity.

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!

I have heard about analysis paralysis, but I think that it is rare. I have never experienced it in any project that I have been on. Planning and design are shortchanged, or skipped altogether, far more often than they are overdone. I am fairly certain that the continued popularity of the term "analysis paralysis" stems from the need for cowboy coders to justify themselves while denigrating the efforts and concerns of those who advocate a more reasoned approach to software development.

Tim Dudra said it for me, in his post above:

"Talking up front is essential to do something that is worth doing. Yes, if you just dive in and do you will likely get something but virtually never what was intended, never on time, never on budget and always with an excess of bugs. "

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.

Another vote for changing your blog name to "False Dichotomy Horror".

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 R&D 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

There is no point to talk, if you have nothing to say. There is no point to talk about problems, if you don't know how to solve them.

Who knows how to solve business problems? The business people. So they must talk to us. If your end users don't know the answers either, then you need to hire 3rd party business people to talk.

You don't need models if you are able to cope without them. In many cases you really can't or you soon realize that you are doomed. The models represent how things should be. If you don't have the models, peoples' memories mix the real world up and add something new to it before you have any version of the software ready. You should make sure that your customer approves your models too.

It is easy to end up with a undocumented crap project that is late and has huge amounts of bugs. You started coding, but the last 10% takes 90% of the time to implement. This happens when you don't have specifications, designs, and architecture.

Surely it is easy to start coding and do some fancy features. But when you are in a project that produces code like million lines, it starts to be really pain to see what affects what if you need to change something without documents.

Great architects don't talk about architecture. They do it. Of course they study and share experience with others, too. Also the architecture improves from version to version. And the helpers of the architect make sure, that the design guidelines of the architecture are followed.

What comes to other documentation like software specifications: Of course you need to gather all the requirements and then design the overall system. Its not the programmer's job to solve what the software has to do eg. in ambiguous business situations. The business analysts and people who make software specifications decide, what the software is supposed to do in what situation. And the programmer doesn't remember gazillion exceptional situations, but you have to create some kinds of execution flow diagrams for him.

How on earth can a company that produces software for commercial gain estimate a software project's potential value unless there is investigation, planning, documentation, etc? There seems to be an implicit assumption that coding is doing and doing is coding. Is not planning doing? Most coders are talkers since I haven't yet met a silent one.

By definition, everyone who posted is a talker and not a doer.

I'm a listener. I listen to what the user/customer/manager says he wants and why he wants it, then I go code the appropriate solution (which is usually much different than what was asked for). I think talkers use up a lot of time trying to make sure everyone is on the same page, which is fine, but if you have the right 'architect' (no matter what their actual job title is) talking directly to the person with the problem to be solved, the amount of talking necessary should be greatly reduced.

If adobe is a company of doers why in the hell cant go and fix their bloddy code bloat. Look at acrobat!!

"In my 12 years, I have seen a lot of talkers. They all had one thing in common, they got fired."

In the Public Service they get promoted.

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

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.....

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.

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]

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!"

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