Good point Rick. I also think that this is an important attribute for all team members, not just leaders.

One of the criteria I use when hiring developers is: do they read technical blogs? I’ve found that people who read technical blogs tend to be much more aware of emerging trends and technologies - as you said, not to chase every buzzword but to have a general awareness of what’s happening as an input to identifying and pursuing promising emerging technologies.

@Cote: our comments crossed in the ether - I just read your reply to Bill… all is right with the universe again. :)

@Bill: I’d add one more tweak to the leadership picture - talented, right intentioned, but not aware of something new. Since there are multiple forms of the Right Thing, they may settle into something that is working well. The PC can act like a scout - they’re more likely to be aware of leading edge ideas, techniques, etc. A good leadership will be receptive, even if they choose not to adopt every suggestion.

I categorize bad leadership in two ways:

- bad intentions (e.g. goal is individual acknowledgment and power hoarding, CYA and blame if something goes wrong)
- ineptitude (e.g. good intentions but don’t have the mental, emotional, or technical talent to succeed)

In the first case, it’s probably impossible to effect change, in the second case it may be possible but it could take a very long time.

But if you have good leadership (talented + right intentioned), you’re probably doing a lot of the right things already, and the organization will be amenable to change because you’re intent on doing the right thing and also you’re smart and confident enough to respond positively when one of your employees (or you yourself) spot suboptimal parts of your process.

So I guess my philosophy is if you’re smart enough to recognize the attributes of a healthy software development organization and you’re not currently in a healthy software dev org, quit your job and go to a healthy env, because it’s a futile exercise to change an org lead by folks who are either too incapable or ill-intentioned to have already fixed the org.

Note that a highly productive development organization doesn’t necessarily mean you work 80 hours a week. I work for what I consider to be a very productive team and heck, I still find time for the occasional blog comment ;-)

Again, totally obvious in an intuitive sort of way, but in my experience, hard as hell to actually implement.

Let’s stop putting the perfectionist obsessive at the top of the pyramid… they can be valuable, and they will often make a product much better over time, but they’re not some ultimate standard - they’re simply one style of coder. Useful, perhaps critical in some cases, but to elevate them above the rest of the team is an affront to people who may care very much about their code and their product… but who chose not to stay up until 3am fixing the most obscure bug ever.

As you point out, developing software and developing the process that goes along with it requires a lot of energy to not only figure out what the right thing to do (code or organization wise) is, but to actually expend the energy to make sure it gets done.

So, if you determine that doing things iteratively is The Right Thing, and yet your team doesn’t do things that way, there’s a certainly amount of energy to spend to change things.

Now, the passionate employee will spend that energy, going up against the metaphoric brick wall of change resistance until either (a.) they effect change, (b.) they leave, or, more likely, (c.) they figure out how to subvert the resistance to change and do The Right Thing anyhow.

The larger point is that I’m suspecious of organizations that don’t make that sort of review, consider, and change part of their culture. Instead they rely on (intentionally or not) heros putting in the effort to change without help from the company.

Now, narrowing down the software development, the thing that rubs me the wrong way about the “just get really good coders” line of thought is that it doesn’t seem like a reliable, long term way to make software. There are not enough of those people to go around, more than likely they won’t stick with you over the life of the product, and, as you point out, there are process adjustments to make to deliver software that don’t rely on heroics from employees.

I suppose the prime assumption here is that an organization doing software has to be oriented around changing the process as called for by the context, where the context is not only the traditional customer inputs (requirements and stories), but also the internal “requirements” and constraints of the company itself.

Now, that’s all obvious and good, but it’s the point in most everything I read where you start to get a lot of hand-waving and clever answers instead of pragmatic how-to’s.

How’s that for a crack at it?

Oftentimes the motivation for this is that you’re working on a feature and there are too many unknown unknowns to really make informed design decisions, so the trick is to quickly work through a first iteration, kludges and all, gain understanding and experience from the effort, and use this new understanding to make an informed design/implementation decision later.

The risk of ‘doing the right thing’ in the face of unknown unknowns is that is that if you end up re-defining the problem you’re trying to solve (as you often do upon reflection), your fast/robust/secure solution now lacks an even more important property … relevance.

Once you decide that indeed you’re solving the right problem and you understand the key design constraints - usually after 2-4 iterations, it’s a good idea to do the right thing and make your design fast/robust/secure.

PS - If any of your iterations span a release to customers, then of course the equation shifts back towards ‘doing the right thing’, even if you have to chuck that extra work later, esp. w/r/t security.

What I meant was putting in the time to do the something that would take more effort but be a better solution when there was a easier solution available. Being quality instead of being cheap” and getting home on time.