Tuesday, May 22, 2007

12 more things that will really help your team

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/12_more_things_that_will_really_help_your_team.htm]

Every enterprise software department should have some basic processes and standards. Joel Spolsky has a great list here. There are some additional things that will really help your team:

  1. A team vision - What really is your team striving for?
  2. The willingness to pay for talent - Because a good developer is much more productive than an average developer, it is only cost-effective to pay for good talent. A CXO whose business model is to get cheap developers will probably be as successful as a cook who tries to save money by buying moldy ingredients. On a related note, a department needs to retain it's top talent. Managers need to ask themselves - why would our top developers stay here?
  3. Thought Leadership - By contributing to the technical community, via articles, presentations, blogs, open-source, etc..., a department (1) shows that they're doing innovative work, (2) shows that they have the intellectual muscle to break new ground, and (3) creates a sense of company pride. This helps market the company, making it more attractive to top talent.
  4. Innovative Process - Are your processes better than they were a year ago, or did someone set things up and now you're done "wasting time" on process? Good process, like continuous builds, automation, and utilities will save your team an immeasurable amount of time. A department that refuses to invest in its process is doomed.
  5. A way to enforce standardization - such as code generation, code reviews, resuable components, and static code analysis.
  6. Tools beyond just Visual Studio, like a file comparison tool (like Beyond Compare), and a non-VSS source control system (we use Subversion). Of course, there are tons of tools out there:
  7. Ways to track progress - How do you know how much more development time a feature needs? Ideally your department has some sort of time-tracking system, with categories for how time is spent. This lets you see how many hours a feature initially took, including the time spent in design, and fixing bugs. If management wants a knee-jerk mentality that always delays doing any good process or innovation because "we don't have the time", a tracking system will give you the hard data to make the business case that you save more time by doing the feature correctly first. I.e. If you can show management that developers spend 50% of their time fixing bugs (both a  high-risk and hard-to-estimate activity), then you can at least explain, in business terms, why it's best to invest in good architecture and process. (If management still doesn't see this, then your department will have a bigger problem).
  8. Automated Deployment - Ultimately every step in deployment should be able to be automated. Doing manual deployment is just too risky and time consuming. It's not just your IT department that needs this - your QA needs automated deployment for performance or functional testing (because QA's environment should mimic Production). Ideally your continuous build will create an install package that your deployment framework can then just install from the command line. Maybe you need to serialize your deployment strategy to an XML file, and pass this in via the command line, maybe you do some manual steps once (like copying your config files to their appropriate locations), but ultimately you don't want to be wasting time manually doing a mission-critical step that could be automated. If a department has some special exception case that they need to do a manual deployment - that's their choice - but at least they'll also have the choice of doing it automatically too.
  9. Hiring of college grads -  If your company is growing and investing in its future, getting smart college grads is a good investment. Most of the brand name companies, like Microsoft or the big consulting companies, have a place for college grads because they know that in a few short years, the smart ones will already be delivering impact. It can also be much easier to home-grow a star than try to poach an established senior star from another company.
  10. Have knowledge collaboration - Wikis (like FlexWiki or SharePoint) are just too valuable to pass up on. If your department doesn't have a wiki "because we can't afford it", then get the open-source FlexWiki. It's free and runs on a Windows XP box. You can have it set up in less than an hour.
  11. Have mentors - Good companies invest in their employees, and one of the best ways for a software company to do that is by having senior devs mentor junior devs. You don't need a suffocating formal process, even just having a senior dev consistently review someone's code, encourage them to invest in certain technologies, or just meet them for a casual lunch, is a good start.
  12. Have career goals - do you know where you, as a developer, want to be in 5 years? Ideally your department has a clearly defined career path. "Better at the current technologies" isn't really specific enough. At Deloitte and CSC (my previous companies), every consultant needed to list several short and long term goals for their yearly review. This forced the consultant to think  about their future, and gave the consultant something to shoot for.

In hindsight, it's east to say "we should have XYZ", but most departments lack these things. In my experience, it's a combo of: (1) an inexperienced department that doesn't know what they're looking for (I've certainly been there when I was younger), (2) lack of budget to build this infrastructure, or (3) lack of motivation for developers to build this infrastructure. If your department is missing a lot of things on this list, and you think it would help your specific case, you can try gradually chipping away at them one-by-one.

Once you start doing a good process, you wonder how you ever could have have lived without it.


Living in Chicago and interested in working for a great company? Check out the careers at Paylocity.

No comments:

Post a Comment