It is sometimes hard to find out what events/activities are occurring for software developers in Blacksburg. This is a super small, non-complete list of things to do.
For VT students, there are a few more.
Let me know if there are other groups I can add to my list.
A long time ago when I was a team lead, we were in a planning session and I made up the rule of doubling. Jokingly, I said we should just double the estimates of all our developers (at the time estimates were in hours or days, not story points). The reason behind it was the fact that doubling would make the outcome more realistic, as I knew the developers were vastly underestimating tasks.
The problem with the rule of doubling is that it compounds. When I told someone how long a feature would take, they doubled it. Then, when that person told someone the date, the next person doubled it. What’s even crazier is the rule of doubling actual yields pretty good results. So as an organization gets larger, the rule of doubling is really the root cause of why projects take longer to get out the door.
I know what you are thinking, I am crazy but it is true. The rule of doubling is a real thing! Why?
There are two main reasons. Developer estimates have very little to do with releasing software and because you never take the time to make the rule of doubling not true.
Developer estimates have very little to do with releasing software because coding is not the only variable involved with releasing software. A great example of this is an article published 7 years ago entitled, How many Microsoft employees does it take to change a light bulb? Microsoft is definitely an extreme case, but I still experience a very similar reality. To release a new feature, the following parties are usually involved.
It seems like a lot, but at Rackspace we take Fanatical Support seriously, and what that means from our software development teams is a lot of time spent to release a quality product. I honestly wouldn’t get rid of a single part of this process. All of it makes our software better and hopefully our customers happier.
This is why story points are more accurate. They measure relative size of different pieces of work and then apply past history to estimate for the future. Don’t forget that story points mean absolutely nothing to organizations or customers. If you can’t use story points to give relatively accurate delivery dates, they are worthless.
Because you never take the time to make the rule of doubling not true means that the inefficiencies that slow development teams accumulate over time rarely get fixed. Developers can easily miss the forest for the trees, working slowly on features instead of fixing inefficiencies to work faster on those features. Bad build scripts, lack of testing automation, crappy development environment, and repetitive manual processes are all build ups of technical debt that need to get resolved at some point.
The solution is good Software Development Managers. Managers need to understand the true cost of developing software, both from an initial implementation standpoint and a future maintenance cost perspective. All to often, managers don’t understand software development and hinder a teams success by setting up unrealistic expectations.
As a manager, you need to be able to set realistic expectations around timelines and also make decisions on what technical debt really needs to get resolved and what can wait. Neither of these are easy and I have made my share of mistakes in these two areas over the years. But, as a manager, I need to constantly remind myself of two questions.
Are my teams regularly meeting my expectations around releasing software (and note that if they aren’t, that is probably a managerial problem, not a team problem)?
What roadblocks do I need eliminate to help my teams meet more of my expecations?
Since the first piece of computer software was created, there have been defects. We have came a long way since those days, but defects are still prevalent throughout every application. They are reported by testers or end users, and eventually make their way back to the software developers that created them. Or did they?
One thing I have observed over the past few years is the fact that almost all defects make their way back to software developers, but developers aren’t always the culprits. To make sense of this, you can categorize types of defects. I have noticed there are three different types of defects that seem quite common, Functional, Procedural, and Conceptual.
Functional defects are traditional bugs. I do XYZ, expect A but get B. Software developers are the culprit, and the right person to be fixing the defect (and hopefully using automated testing to prevent it from ever happening again).
Procedural defects stem from bad processes, which may look very similar to I do XYZ, expect A but get B. The reason they got B instead of A is rooted in the fact that a process wasn’t followed. For example, a new feature is introduced that changes how a user creates a widget. The documentation is never updated however, because the sticky note fell off the task board. Oops! To the user, this is a defect, but in all reality, the root cause a process problem.
Conceptual defects are the nastiest ones. These are the defects that stem from requirements, usability, or just bad features. Often parts of an application need to be rethought, removed, and vastly improved to resolve these issues. What do these issues look like?
A user can’t create a new widget. They can’t create the new widget because they haven’t met all the criteria to create new widget (but the criteria isn’t easily understood).
Why is it important to understand these categories? Because software developers can only really solve functional defects, but they often deal with procedural or conceptual defects daily. Being a software development manager, I see this all the time.
Functional defacts fall on the software developers.
Procedural defects fall on whoever is playing the role of project manager for a team.
Conceptual defects fall on whoever is playing the role of product owner/manager for the team.
It is important to have a system in place that can handle all types of defects, not just functional. Otherwise frustration will set in on your developers.
Right now, I am sitting in a huge room with hundreds of amazing entrepreneurs, developers, founders, etc. I am at the Business of Software conference in San Francisco. In the next few day’s, I hope to have a few posts up about the conference and specific presentations I really liked.
Stay tuned.
It’s been a little over a week since I installed Windows 7. I tried the upgrade route, failed, and re-formatted the whole machine (every now and again you need to give your PC a good scrubbing). The real question is, what software did I put on the machine?
To give credit where credit is due, I was inspired to do this by Hanselman’s post on the same topic (also, you have to check out his tool list).