Today's lesson comes to you courtesy of your local Department of Transportation:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/12/are-you-a-doer-or-a-talker.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/12/are-you-a-doer-or-a-talker.html
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.
a href="http://en.wikipedia.org/wiki/I-35W_Mississippi_River_Bridge"http://en.wikipedia.org/wiki/I-35W_Mississippi_River_Bridge/a
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.