My Tweets

  • in Austin, TX for the weekend visiting my in-laws...gotta do some tech support for my FIL as well.
  • @CalebJenkins: I think Trudy's in Austin skews that statistic big time...
  • @dpenton: agreed there's always value as it forces SRP and SoC. Dependencies always get abstracted out when unit testing is enforced too.
  • @dpenton: unit testing has value when reqs come from biz analysts. If devs/former devs are involved, reqs get more attention/thought.
  • @jbogard: Common scenario I've seen is when properties have an Enum that does a straight type mapping to the DB. Not a flexible design.

Xbox Gamer Tag

Ideal Software Management

Monday, May 21 2007 2 Comments

Tim Stall had a great post entitled "Why would someone work for your company?" where he outlined a number of things companies can do to be more attractive for top developer talent without breaking the budget.  I highly recommend reading the entire post, but one point in particular got me thinking about software management.

Good developers have the intrinsic need to grow and learn...Any manager that stifles that for any reason will simply push their best developers away. Such excuses may include: "we don't have time", "that's not in the requirement", "just do it this way because I said so", "this approach worked 5 years ago", "your job is to support the business, not research technology", etc...

As a developer, how many times have you heard those last few phrases? I certainly have heard them many times from several managers in all different industries.  Most software managers would prefer to take approaches which they have personally seen work rather than attempt anything new and unproven. 

This view often seems short-sighted, as most seasoned developers know that every software project can have dramatically different requirements and technical environments.  A good software manager has to understand the capabilities of both the available personnel and the technical environment to determine the best approach to the business problem. 

I have seen many projects fail because the management decided to build a solution based on a previously successful approach but used a different set of programmers and a completely different technical environment.  So by attempting to be less risky by using a tried and true approach, the project actually has created more inherent risk by forcing both developers and technology down a path to which it may not be suitable.

It's my opinion that if software management is willing to re-evaluate their personnel and their technical environment before embarking on a new project, they should also be equally willing to try a new approach or methodology as well.

Comments

#1 On May 21,2007 at 8:48 AM David O'Hara said:

There are two directions you can go as a dev - you're either growing or you're dying. There is NO standing pat in this game. And as a manager, you have to provide the environment to foster the former or you're the cause of the latter. I know it sounds trite but it's certainly been my experience.

#2 On May 24,2007 at 8:29 PM Karthik Hariharan said:

Couldn't agree more, Dave.  Developers have to keep learning and need to have a natural love for learning, without it they stagnate and go obsolete with the technology.  Good managers have to recognize that and provide an environment where a developer is secure in their own growth.