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