> I’d add one more tweak to the leadership

> picture – talented, right intentioned,

> but not aware of something new.

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.

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

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.

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 ;-)

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.