Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Are You Smart or Dumb?

  • submit to reddit
What's the difference in smart and dumb? I've come to believe it's two things. How far ahead you can think into the future and how quickly you can do that thinking.

When someone is playing chess, pool, or poker, their skill is determined by how many moves ahead they can think. How much history can they remember, and then factor in to the next move.

In software, how far ahead can you see? Are you using destructive practices because you're so busy "getting work done"? Are you ignoring great practices that could save you time?

Think of this like cutting a road through the woods. You're working very, very hard. Everyone on the team is breaking their backs, sweating, getting blisters, the whole nine yards. No one can possibly question your loyalty or dedication.


When's the last time you stopped cutting down trees on this metaphorical road, and climbed a tree... or checked a map... or sharpened your axe? The problem with most software teams cutting these roads through the woods is that they never check to see if the road is headed towards the town that needs the road. They never check that the road is straight. They never check to see if they can buy a few chain saws to replace those ancient axes the team is using today.

Obviously this can be abused. We don't want to spend all day in the hardware store looking for new tools, but we do need to stop from time to time, take a look around, and see if we're headed in the right direction. Make sure we're using the right tools for the job. See if the blades are sharp.

Here are a few suggestions for tools I'd strongly encourage you to check out.

  • Continuous Integration From AntHill Pro to Cruise Control for Java to Cruise Control for Dot Net, these team wide automatic compilers (and test runners!) can do wonders for your team. It keeps your team writing code instead of fixing compiles, keeps the product clean, and catches problems fast.
  • Frequent demos Whether they're internal, or for your client, these public demonstrations help others understand what you're doing and suggest course corrections. If you're cutting the road in the wrong direction, how much time do you want to continue wasting? Show people what you're doing and find out what they think as soon as possible.
  • Time boxed iterations Provide your team a more effective way to box in their efforts and ensure they're building the right thing. This also provides you a faster stopping point when someone is stuck in the ditch, and can't finish something.
  • Automated testing When you encode your product knowledge in a coded test (run in a continuous integration server, of course), it becomes impossible for you anyone else on the team (or you) to break that code without it being caught very quickly. It's the best way I know to keep everyone on track, catch mistakes quickly, and fix bad habits before they become engrained.
  • Defect Driven Testing Find a bug? Add a test. Always. This extremely focused approach to test automation provides coverage exactly where you need it first. Also, never add just one test... aim for a "Baker's Dozen" of one off derivative tests.
  • Test Driven Development Writing a test before you write your code provides a completely different type of code. It's smaller, more focused, and (big surprise!) tested. A lot of very smart people love TDD... give it a chance.
  • Daily Stand Ups The daily meeting gets everyone together to talk and see each other's faces every day. Answer the three (or sometimes four) questions to help share information as well. How often have you worked on a team where everyone talked to everyone else every day?

I could type these all day... what's worked for you? Has Groovy and Grails been a great new tool in your arsenal? How about Resharper? Tell us what's worked for you.

One last observation... when we're under too much pressure to deliver something yesterday, we stop looking around. Instead we work harder, not smarter. We tend to skip opportunities to clean up code, try out new tools, and improve the process. Instead we make more and more short term decisions. We use the tools we have instead of trying out new ones. Instead of taking 10 minutes to sharpen our saws, we cut for an extra two hours with the old, dull blade.

Don't let the demands of your job make you stupid.
Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mats Henricson replied on Mon, 2010/05/03 - 6:55am

Is a spell-check of the title of an article sent to tens of thousands of people too much to ask for?


Jared Richardson replied on Mon, 2010/05/03 - 7:14am in response to: Mats Henricson

Hi Mats... I see that I missed "team wide". Is there something else you feel I missed?

Jared Richardson replied on Mon, 2010/05/03 - 8:02am in response to: Jared Richardson

A few friends emailed me and pointed out the title... "Are You Smart of Dumb" should be "Are You Smart Or Dumb"... it's fxed now.


I guess I've answered that question for myself.... ;)

Mats Henricson replied on Mon, 2010/05/03 - 9:51am

It just takes down the impression of the whole article when it starts with a incorrectly spelled title. I actually dismissed the whole thing because of that. My line of thought was, "What credibility does a writer have if he doesn't even check the title of his blog before posting to thousands upon thousands of readers"? I'm sorry, but I take stuff like that seriously. Would I trust your checkins of code, for example?

Jared Richardson replied on Mon, 2010/05/03 - 10:24am in response to: Mats Henricson

I understand. Usually for things like this I look over the article carefully, but the title is typed in by hand at the last minute. I'll be more careful in the future, but a spell checker wouldn't have caught that problem. I spelled the wrong word perfectly. But I will be more careful next time. I don't know if you took the time to read the article, but I'd welcome your feedback if you do.

As to code check ins, that's why I use continuous integration. ;)

Jason Marshall replied on Mon, 2010/05/03 - 1:32pm in response to: Mats Henricson

You really need to learn to relax, Mats.  This level of vitriol for a typo?  Maybe you should talk to your doctor about hypertension before it kills you.  I'm entirely serious.

Half the tools the author discusses in this post are designed to remove exactly the sort of constant vigilance that you're demanding.  Can you trust that my code doesn't have a typo in it?  Damn skippy you can.  Because the system would catch it.

Everyone is software development is a human being (and you would do well to remember that, because you seem to be having a little trouble with people), and humans have their ups and downs.  I like to say that I use my A-game days to protect myself and my teammates from my C-game days. Long-term, strategic planning should come when you're in a spot where your feel comfortable to tackle the task (and if that's 'never', then you need to fix that first), and the rest of the time you should be executing on your plan.  

It's a little like navigating in the woods.  Plan your route on hilltops, and just stick to the plan when you're in valleys, and you're likely to get where you're going.  Doing the reverse will just leave you walking in circles.

Mats Henricson replied on Mon, 2010/05/03 - 3:39pm

Jason, I take claims of vitriol seriouly (I was just doused by some of that today in a totally different forum), but I can't see where I was vitriolic. What I said was that I take being careful serously, especially when probably tens of thousands of people is looking. Is that vitriolic? If so, then your claim that I must have "a little trouble with people" seems just about the same, no?

How do you react if you're sent a resume for a job application and the first sentence is spelled incorrectly? Unless you just have a few resumes, I bet that misspelled one goes to /dev/null. What I'm saying is that, the more there is at stake, the more care you take. If you have the privilige of having tens of thousands of readers, then reading through your text a few extra times makes a lot of sense. After all, the text will be read ten thousand times more than it is written, so as a courtesy to all readers, I spend extra time proofreading.

And, the tools suggested can't catch spelling mistakes in texts that are printouts to users, for example. You still need vigilance to catch those.

And, if you think that was vitriolic, you should see what I can do when I'm in a really bad mood...


Abbas Raza replied on Mon, 2010/05/03 - 10:02pm

Thanks for posting common sense rules as we learn from our experience. Seriously (neither seriouly nor serously :)), these rules ought to be revisited frequently.

Sean Sandy replied on Mon, 2010/05/03 - 10:34pm in response to: Jared Richardson

Unless you are Dutch, then using 'of' that way is correct, and you are forgiven. ;)

Jared Richardson replied on Wed, 2010/05/05 - 9:23am in response to: Abbas Raza

I agree on constantly revisions. What types of changes have you seen over time?

Jared Richardson replied on Wed, 2010/05/05 - 9:24am in response to: Sean Sandy

Thanks for the forgiveness. ;) It's one of the hazards of "speaking" in public.

Barry MacMahon replied on Fri, 2010/05/14 - 4:48am

My problem has never been ignoring new good practices or tools but rather having to convince people further up the food chain that it's a good idea to use them. Time and time again I run into brick walls trying to get things done according to best practices.

Currently I managed to sneak in a bit of GMock for testing and it basically made it possible for me to test loads of stuff I wouldn't have had time to otherwise, and I actually have a team lead telling me they would rather delete my tests than fix them because they are irrelevant to him seen as he refuses to run them. I even very gently explained that there's perfectly good native support in Intellij which we are using. This is a slighly extreme example but very real one none the less.

Sometimes I feel like the only one who reads the web!

Having said all that we must be wary of "Digital Maoism" , dare I say I'm glad I didn't invest more time into RoR ! :-) Well I am a java developer.


Jared Richardson replied on Sun, 2010/05/16 - 12:26pm in response to: Barry MacMahon

I have a few suggestions for you.

First, never sell a solution on its technical merit. As you move up the food chain, no-one cares about technical merit. They care about how much $$ is saved. So show them how much $$ they can save by having automated tests catch problems before products ship. Talk about how code reviews and pair programming break down knowledge silos, lowering the cost of carrying on when a team member leaves. How daily meetings raises the level of team wide communication, catching problems more quickly.

Second, make it as easy as possible to do the right thing. If you are driving test automation, run it within a continuous integration framework. Don't expect developers to run your automated tests at first. They've got to see the benefit first and a CI system can illustrate the benefit. But be prepared to do most of the fixing yourself at first.

Don't start with tests that are intricate, tricky, or clever. Target the bugs that blue screen the machine or crash your program. Write the simplest possible test to expose a black and white issue. At this stage you are trying to convince people of how useful these ideas are, so target the biggest return for your test investment. And you write the simplest possible test to make it easier for people to understand, fix, and later copy, the tests you've created.

Finally, ditch the mocks for now. When starting a test automation effort you're trying to sell a group of people on a number of new ideas. Adding mock objects to the mix just increases the learning curve. Go for plain unit tests w/o mocks or integration tests. Make it as easy as possible for your team mates to understand what you're doing and see the value.

It sounds like you're doing good things. Work on your sales pitch a bit and you'll make more progress. Also, you never know how many of the seeds you've planted are growing. I suspect you've done more good than you realize.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.