Proposal for Director of Software Development
Date 03/24/08
Initial Plan
Any time someone takes over a new position or responsibility for the first time, the first thing everyone wants to know is well, what’s your plan?
Plans are, by their very nature, expensive. They often consist of multiple steps, which in turn are dependent on both controllable and uncontrollable factors. A decent amount of time is spent creating and documenting a plan, but it only does one thing for you: it tells you what the next step should be. Once you’ve taken that step, you have to start over. Not from scratch, mind you, as much of your previous calculations may still be valid.
Development
Step 1: No more delays on promulgating the testing philosophy. Lead by example: write tests and check them in; talk about tests; send emails with output of tests when asking someone a question or reporting a behavior; bring up questions about certain tests in meetings; push questions about how certain changes proposed in a code review fared against the regression tests. Start the training by having a tech talk or TOI about how the harness works, how to write a test, how to run a test, how to set up a testing environment, and so forth.
Step 2: Create general development plan and process flow for producing a release. This would include steps taken by QA, CS, and Marketing/Sales. Get buy-in and consensus.
Step 3: Create a software development web page that shows a frequently updated list of what projects software development has officially in it’s queue, and what those projects are rated, what release date they are slated for, if any, what are currently in active development, and so forth. This would go a long way towards proactively communicating with other internal company groups.
Efficiency
Step 2: Increase long term developer efficiency. Do this mostly by concentrating on tools and process.
Put together a plan to replace Clearquest with Bugzilla including migrating current data, training, etc. I already have Bugzilla installed on ripper.onstor.net so that it can be demonstrated and test driven. Integrate bugzilla with our SCM tool, Perforce. Perforce has this capability built in so it should be pretty simple. Start by pulling together an estimate of how much money and productivity will be saved by such a switch.
Write up and get ratified clear guidelines for coding style, checkin comments, and code review procedures.
Solidify developer processes: test code development; design reviews and their entrance and exit criteria; change revert requests.
Step 3: Increase the formality of some of our coding conventions, including coding style and checkin comments. Build energy and desire around having these things checked as part of the review process. As the general professionalism of the team increases, so will it’s morale and self image.
Morale
Step 1: Start programs to increase team cohesion, energy, and morale. I’m thinking at the very least, renew the weekly software development meeting, but in addition a hosted Friday lunch with no agenda, just socializing and whatever other topics people feel like talking to each other about. Plan other activities to recognize development accomplishments like going to Live Free or Die Hard. Reward people who show diligence in their job duties, something that is distinctly lacking sometimes, even in senior developers.
Equipment
Step 1: Modernize workstations and workstation software. Most developer workstations are many years old. A semi-modern quad-core, 4GB workstation with a semi-modern version of Linux will cost around $500 and drastically increase productivity by reducing build times by as much as 66%. Not to mention the speed of other developer tools such as search, editing, indexing, etc.