Main Contents
organization, management, software development
Comments (1)
Two weeks into the new app dev manager with a new organization. After moving through this transition a few times I can pass on the following advice:
- Start your one-on-ones or continue the existing ones.
- Spend a lot of time talking and walking around. Your brand new, and you need to get out and start getting a sense of the people and the organization.
- Gather your project and application portfolio. At this point the acronyms and lingo are still confusing, but you have to get a sense of where your projects are and whether any of them are struggling.
- Stay organized. You’re on a nasty learning curve for the first few months and the last thing you want to do is let your email, physical inbox, and voicemail start overflowing. (GTD works for me here.)
- Enjoy the surprises. Every organization has it’s own way of doing things and at least once a day for the first few weeks you’ll have some underlying assumptions shattered. In an earlier job in my career I remember picking my jaw off the floor about one week in. One of the developers on Project X Phase II explained Project X Phase I had never been deployed to production. Some unrelated projects had been rebranded as Project X Phase I so the team could declare victory on delivering phase I.
- Don’t make big changes those first few weeks. You don’t have the data yet.
Ed Gibbs @ April 26, 2008
automated builds, software development
Comments (6)
This week I started fresh with a new company and a new title. After four years as a Software Development Manager and a short stint as an Enterprise Architecture Manager I’ve now returned to managing a group of internal IT developers. The current title is Application Development Manager.
The new organization is full of opportunities and challenges. Some of these include:
- Inheriting a senior development team.
- An organization which is still early in the process of formulating practices and process.
- High level support for process improvement a mix of CMMI, ITIL, PMI, and a bit of RUP at present.
- Systems with real high availability requirements.
- A JBoss shop.
- A QA team pushing hard to push for quality throughout the project and not just at the end. Plus they’re doing automation and load/performance tuning.
- Developers self-organizing a weekly gathering to discuss software topics.
I wake up about 5 am these days to go for a walk every morning. These days it’s a lot easier to bounce up and not just hit the snooze button. If I can get Perforce setup with a Hudson plugin I might just set up a continuous build box tomorrow.
Ed Gibbs @ April 17, 2008
automated builds, test driven development, software development
Comments (2)
A sense of fun can help new practice adoptions. After reading a post by Clint Shank on coming up with a continuous integration game Erik Ramfelt went ahead and created a Hudson plugin.
Currently the points you get are:
- -10 points for breaking a build
- 0 points for breaking a build that already was broken
- +1 points for doing a build with no failures (unstable builds gives no points)
- -1 points for each new test failures
- +1 points for each new test that passes
Looks like a good starting point. I really like the idea of getting points for implementing new tests.
Ed Gibbs @ April 14, 2008
management, software development
Comments (2)
As a manager of developers I have a goal of trying to provide at least one week of training per year at a bare minimum. For senior developers or even journeyman developers in transition the best available option is often a conference. The benefits far outweigh the costs:
- Exposure to software development outside of your small corporate IT shop. I know people read blogs and books about software, but talking to real people can bring the message home. I had been evangelizing things like TDD and continuous integration among my developers, but when I sent four of them off to a conference they all came back saying, “Wow, this TDD stuff, design patterns, and agile really are big deals. I had no idea.”
- Proving your company really is about the people in it by investing in them. There’s lots of talk at most companies about how much they value their employees, but when it comes down to it training requests are denied on a regular basis. And since so many companies pay lip service to training actually providing it can be a major recruiting advantage.
- One conference can pay dividends throughout the year. Your developers come back with lots of new ideas and continue to research and bring these ideas into their day to day development. Your code base will actually get better and your developers will be more productive. And that extra kick in their step around the office is the sign of a re-energized employee. Energized employees are a great asset.
Unfortunately this is the most common experience:
Nearly a year ago, I posted a question on Spring Forum entitled, “am I working for the wrong companies or is it just not that common to attend conferences?”. I’ve worked as a developer for over six years and as yet I’ve never had the opportunity to attend a single conference. I thought I might be alone in this, but I’ve spoken to a large number of developers who are in exactly the same position, some of whom have worked in the industry far longer than I have.
Ed Gibbs @ March 23, 2008
scheme, software development
Comments (1)
After some debating I came across the much talked about book, The Little Schemer, at the Borders near Union Square in San Francisco. It compelled me to make a purchase and I’ve slowly started going through the examples. I really like technical books where you don’t actually have to be on a live computer to constantly try the exercises. And the cartoon elephants make me happy.
Next steps:
- Install an xUnit in this case, SchemeUnit
- Install a text editor/IDE looks like DrScheme. (Even OS X screen shots)
Ed Gibbs @ March 2, 2008
acceptence testing, ruby, test driven development
Comments (0)
I haven’t really spent a lot of time with RSpec since about the 0.5 release. I took a tutorial class with Dave Astels and got jazzed about the opportunity since they were really able to leverage Ruby to make a nice BDD framework. After using RSpec all JUnit test methods started including should. The Rails integration back then was a bit flakey and I just dropped back to Test::Unit.
Version 1.1.2 plays nice with Rails and the momentum of RSpec has definitely picked up over the past two years. Spending time using Story Framework looks compelling as an option for specifying functional/acceptence/customer tests.
Ed Gibbs @ January 28, 2008
project management, scrum, software development
Comments (1)
Agile is really designed around software projects. Infrastructure is a different animal. With an infrastructure project some things start to break down:
- You usually aren’t writing much code, maybe some database install scripts so no unit tests.
- Often there’s no continuous integration to speak of.
- Configuration tasks on new software are often difficult to estimate.
- Many tasks end up being time-boxed research items.
- Team members tend to be specialists DBAs or Linux system admins.
- Most of your team are system admins, but often they aren’t dedicated.
I’ve done a few of these now and generally the most difficult part has been having dedicated staff. System admins and DBAs structure their days around reacting to issues and answering many small requests. The idea of dedicating whole days or weeks to a project is novel. Too novel perhaps as often their management chains are unwilling to dedicate resources.
Our approach has been to use some Agile practices like daily stand-ups and task boards, but these practices haven’t made for smooth infrastructure projects. Since our QA team has been investing in automated functional tests we now have regression suites for some of our major projects, but that’s about the only automation we’ve been able to make use of. It often comes down to a PM/Scrum Master who’s willing to constantly remove impediments by walking around making sure the project keeps moving forward.
Ed Gibbs @ January 14, 2008
enterprise architecture, automated builds, software development
Comments (2)
Continuous Integration can be a great place to do governance. With good reason developers get the shakes when someone mentions we need more governance. Past history has taught them governance often means someone above them says no.
Continuous integration allows you to inject good development practices and ensure some governance without having to always be the bad cop. Let the build box be the bad cop.
If you’re a Java or .NET shop you can add all sorts of checkpoints to the build and tell at a glance where projects are at and dig into the details. The sorts of things you can do include:
- Requiring every active project have a build script and be setup on the build box.
- The code must checkout completely and compile successfully.
- There must be tests and all tests must pass.
- Unit test coverage must meet a target number or the build fails. (We use 70% currently)
- Coding conventions must be followed or the build fails if you have more than say 20 violations. We use Checkstyle to enforce this.
- The code passes the CRAP metric.
- The code passes other static analysis checks like Findbugs or PMD.
- Package dependency analysis using thing like JDepend.
- Security static analyzers to prove code meets security standards. (I haven’t tried any of these yet.)
All of these steps help you promote good practices, ensure transparency, and give you governance over day to day coding instead of just a review or two at the beginning and end of a project.
Ed Gibbs @ January 10, 2008
management, software development
Comments (4)
Ran across a wonderful rule when putting together your annual goals.
“A goal that a dead man can meeting is pretty useless.”
- (Comment on Manager Tools)
Some potential dead man’s goals:
- Improve automation on projects.
All I need to meet this goal is a single developer with an ounce of effort to create a single ant file or shell script. I don’t have to be alive to meet this goal.
- Engage more with business customers.
If one of my developers talks to a salesperson in the hallway, check, done.
No one said they had to be big projects, maybe a small production bug fix counts as a project. Again a team could probably do this without any manager.
- Perform maintenance on System X.
Everyone has maintenance, check.
The guys at Manager tools have a really simple model. The goal just has to be measurable and time based. Thus the goals become:
- Automate all projects with maven by November 15.
- Meet a rating of good or better with an annual survey of customer satisfaction for internal customers by September 1st.
- Deliver Project X with less than 10 severe bugs by May 25th.
- Reduce maintenance costs on System X by 50% by December 30th.
Ed Gibbs @ January 8, 2008
