The Will to be Good

I've come to the conclusion that the single most important attribute of an
effective software team is simply the will to be good.  Talent can be
developed and knowledge gained, but not without the will to get there.  I'm
obviously a big proponent of Agile practices, but these practices are useless
unless the team is disciplined and intelligent in their approach.  If you
want to be good, you have to be reflective about your approach every day and
constantly make little improvements. 
Don't Live with Broken Windows yes, but you've got to be observant in the first place to spot those Broken Windows. 
Complacency is the enemy.

I don't think a team is going to be good by simply working harder. 
Ironically, my most important lessons for software development came from working
on my father's construction crew in school — "always think about what
you're doing" and the paternal classic "work smart, not hard." 
He was worried about things like walls getting out of square or hurting your
back lifting, but those little homilies certainly apply to our profession. 
Effort
alone will not lead to good results.
  Some of the worst systems I've
ever seen resulted from taking a bad direction and following that same bad
direction for the duration of the project, often with a great deal of team
effort.

Don't tolerate bad code.  If you see your code starting to get wild and
wooly, refactor!  Little refactorings are the ounce of prevention that
prevent the painful rewrite cure later.  Pay attention to your code so you know when to refactor. 
That "pay attention" could be code reviews, code metrics, pair programming, or
simply reading the code you just wrote.  Bad code will increase the
cost of debugging, testing, and modifying the code later.

Don't write code on top of bad code.  I failed to make this point
adequately
yesterday.  My current team is effectively evaporating and we're passing
our upcoming project onto a different team.  The new project is going to
require modifying some existing classes that can only be described as pure excrement. 
There's far, far too much duplicated code in a very long method and class (Cyclomatic
Complexity = 50+). 
The new team wants to make the simplest change they can to just add in some more
if/then logic and walk away.  That's a dangerous attitude that will hurt
the team over time.  I know that attitude has hurt my company.  Arguably, that code is in the shape it's in because of exactly that attitude of "I just have to get this done."  On one hand, I think the new code would go
smoother if you cleaned up the old code first.  On the other hand, doing no
cleanup is going to increase the chances of a full blown rewrite the next time
that code changes because it's already at the verge of being unusable.  The
key point is that the
new changes would be relatively simple if the original code had simply been
built cleaner.  I really do think that some minor refactorings early on
could have prevented the poor quality code with much less effort than it will
take at this point.

Fix a broken build — immediately.  As soon as you stop taking a
Continuous Integration build seriously, whatever it might be, you have lost all
the value of doing a CI build.

The "design hat" never comes off. 

Scott Bellware
and

Sam Gentile
have both posted recently about their feelings toward continuous
design and the role of an architect or design leader on Agile projects. 
Pushing aside the definition of roles and responsibilities on a project, doing
continuous design effectively requires the team as a whole to adopt an attitude
of constant challenge to their design.  Talk and think
about your design. Analyze the effectiveness of your design over time.  Don't act on a design
idea until it's time, but do think about the future and keep a running queue of
design ideas circulating in the team.  All of the worst systems I've ever
worked with shared a common history:  the team picked a technical direction early that
wasn't ideal, then thoughtlessly marched along said flawed path without any
thought for altering the design. 

If a manual build or deployment process is repeatedly slowing you down, automate it! 

If you're producing too many bugs, think about changing the way you unit test
or code.

If your estimating practices or project management processes don't seem to work, change them. The "process" is there to serve the team, not the team
existing to serve the process.  If you think iteration kickoff meetings are
some sort of sadistic exercise, you've got a severe problem that needs to be
addressed.  If you hate the process, it needs to change.  Grumbling
never seems to help — .

Does Quality Even Matter?

Absolutely.  If you're like me, your management doesn't care or understand, but
quality absolutely matters — even to management, they just don't always
understand the implications.  Quality code, configuration management, and
testability maintains the level of the team's
productivity.  Bad code degrades the team's productivity over time. 
Good designs enable efficiency in supporting the code later.  Bad designs
increase the cost of ownership. 

Almost without fail, anytime somebody posts on a design pattern or design
approach, another person will comment that they don't have time for all this academic nonsense because they're too busy building code under time constraints in the real world.
Regardless of process or philosophy or technology, the best teams are those that
ditch that attitude of "I can't stop to sharpen
the saw because I'm too busy cutting wood!"

Besides, there's that little "pride in your craftsmanship" thing too.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jaakko Haapasalo

    I was just reading Peter F. Drucker on management, and this post reminded me immediately of what he says about efficiency (doing the things right) vs. effectiveness (doing the right things). A knowledge worker needs to be efficient of course, but much more important is being effective. One of the components of effectiveness is a focus on contribution, not work. What can I contribute to further our project goals (for example)? This seems to me to come pretty close to the idea of The Will to Be Good discussed here, at least as far as continuous design and thinking about the project direction are concerned.

    (Drucker’s work is a /very/ recent acquaintance, so I probably won’t be able to elaborate much beyond this.)

  • http://codebetter.com/blogs/sam.gentile SamGentile

    Well said as always man.

  • Carlton

    I believe this is what Scrum refers to when it refers to the idea “we can do better than the status quo”. For a lot of people, the status quo is good enough. IMO, what is often considered “good enough” hardly qualifies as professional.

  • http://harmons.blogspot.com Chris

    Hallelujiah man.
    You know it’s funny because only the people I have known who believe these principles are those that would be likely to have heard of blogs and would be subscribed to something like this. All the developers who *should* read this don’t even know this sort of stuff has been written and available!

    Regarding pride in craftsmanship – at my last job, on the last day I was calling a guy that I did some software for and was asking how it was working and if he needed anything and my then boss couldn’t believe I was actually calling (as if it was impossible to believe I was actually concerned with the software I made for him).

    Those who will to do good are concerned with quality and teamwork, software design, proper tools, helping others, reliability & maintainability, etc., etc.

    Now the question is – how can you promote others to be good? I have always tried to be helpful to others (aka being good).. but what have others done?