Keeping it clean
Filed under: Development, Management, Process, Product Management, Project Management
The bug databases which are used as they should be, are very susceptible to having a back log of old issues (bug rot). These old issues will grow and grow as time marches on. Any reasonable person who examines of the size and requests in the database results in the conclusion that they can’t all be resolved.
During a triage we ask, “When should we fix this issue?” The response typically is either, “Now” or “Next Release”. Many people are afraid to ask this question, “Will we ever fix it?” There are some issues that we will actually fix in the future, but that list will always be smaller than what we won’t fix in the future. If we are never going to fix them, why do we keep them around in an open state?
There are several reason people choose to push a bug to the “Next Release” instead of choosing not to fix it. By telling a person we aren’t planning on fixing your issue, it leads to longer triage meetings since you will have to have a more vigorous discussion on a bug closure. It is much easier to placate with a, “We’ll fix it in the future, we’ve got a release to get out the door right now”.
I’m a person who enjoys stats and the bug database. When the bug database is properly used by the developers, it is a good way for me to get a feel as to the quality and progress of a release. The result of choosing to move your issues to the “Next Release” instead of considering closure will cost you in the long run in the following ways:
-
Groundhog day
We have to constantly discuss these same issues again and again is insane. When we are releasing M6, we are moving many issues to M7 since we know that we won’t have time to resolve them in M6. Once we start development of M7, we go over all the M7, moving many of them to M8. Repeat this process again and again. This results in us having to discuss these same issues again and again. Those issues that we continually bump will never get fixed. Close them as “WONTFIX”, man up and just do it. -
Zarro boogs found
It clutters up the view for the developers. It is much easier for a bug to get forgotten when you have 200 assigned to you, instead of only 22. Seeing that my bug list empty, is just as satisfying as all of my unit tests as green. -
Component Health
Measuring the health of your components is much more difficult. With all of these old issues cluttering the database, the view of the software components health can become skewed. I could see in the database that there are 420 bugs against “Component A” which could be in a much better state than “Component B” with only 80 bugs against it. -
Projections
I use the database to do bug glide slope projections to help me determine if we are converging or diverging. Carrying a large amount of bugs make the projections more cluttered.
I will say that there has been a couple of times where I’ve broken the “WONTFIX” rule. There have been requests from the senior management team which are clearly impossible (usually defying the law of physics), and no amount of discussion can get them to drop it. These bugs get logged, and targetting approatiely. We typically visit these in the begining of the release cycle to ensure that they are given due consideration so that when we can provide an intelligent response.
Are we there yet
Filed under: Big Company, Crazy, Development, Management, Project Management, Small Company
Asking developers on an hourly basis if they are done, will NOT make the fix come faster. Just because you are receiving pressure from above, doesn’t give you a license to kill productivity for all of those around you. Now is when you need to control the situation and get things done by helping your team. This is not the time to request for up to the minute status updates and TPS reports. Interrupting your developer’s concentration constantly doesn’t help them work. Try the following instead:
-
Make sure the correct amount of people are dedicated to the problem. There are many times when less is more (I’m not just talking about the editor), where the right two people are infinitely more effective than the wrong 20 people.
-
Distractions must be minimized to ensure their focus doesn’t drift from the current work to other priorities.
-
Provide the stakeholders with accurate updates on progress. If there is any heat or anger related to the issue, take it for the team so that they can focus on fixing the issue.
-
Ensure the developers understands the issue, context, and time lines.
-
Remove roadblocks soon as quickly as you can (or ahead of time if possible).
-
Get the developers what they need to get the job done right.
Clear the path in front of them and let them work, don’t hold them back.
Students – The Many Month Interview
Filed under: Big Company, HR, Management, Small Company
The purpose of students is recruiting for full time employees. Their work terms are their interview. At the end of the term, you will have a good idea if they would fit into your organization.
Many companies have a probationary period, but it is usually not long enough to evaluate the effectiveness of the employee. With students, you have a 4 to 18 month term. Students will leave at the end of the term unless you ask them to stay. Full timers stay at the end of the probation term unless you ask them to leave (which usually tones of paper work).
Many people say, students are cheap. I would say that this needs to be clarified. Students are a cheap way to recruit new hires, but expensive when you factor in training from your full timers. Here are some of the costs associated with hiring students:
-
Resume Reading – I’ve found that marks are not necessarily the best judge of future work place performance. There have been many good people I’ve worked with who have had mediocre marks. The reason I bring up marks is that the filers offered by the schools for the employers are typically useless, resulting in a huge pile of resumes. Multiply this by the number of schools you are hiring from, then you start to see that this starts to add up.
Interviewing – The interview process for students goes much faster than full timers, but you will still need to dedicate half a day to a full day depending on the number of schools and candidates that have been selected.
Work Plan – With most students, I spend time to create a work plan for the term. This plan contains the training plan, ramp up information, and outline of their work for the term. This plan will be added as a template to the template section.
Training – People must be assigned to train this new resource, not manuals. This training (or interruptions) of your regular team members daily activities will reduce their productivity.
Salary – The salary of the student is lower than your full timers. Make sure to talk to accounting if you are in a small company as there may be government grants available to help subsidize their salary.
Now that you’ve got the student, it is important to give them real work. No one enjoys make work projects. The purpose of the student is to help determine if they are material to be a full time hire. This is best evaluated by giving them work just as if they were a regular employee.
Once the work term is over, you should have a good idea if they would make a good full time hire. When you bring this person on full time, their is much less risk and training.
Note: On the government student hiring incentives, there are many strings attached. Ensure that the accounting department doesn’t dictate that the new hires must qualify for the program. I have seen some programs structured so that a student who is in a coop program is unable to qualify as a new student hire because the qualification formula used involves number of hours worked over a period (which can be exceed by those in a coop program).
When not to ship software
Filed under: Development, Product Management, Project Management
When planning a product release, you always choose a date. Choosing a date is difficult, and here are some dates which I suggest you try to avoid.
-
End of the Quarter
If you choose your shipping date as the last day of the quarter, your boss will tell the executive team in his next meeting. Your boss is now on the hook for delivering at the end of the quarter, whether the executives care or not.This isn’t the worst one because if you are late, you can usually get your way out of it by doing a demo to their boss. This demo, plus some nice words can usually buy you more time. The good thing about the demo is that it gives you a good wake up call of how far along you really are.
End of Fiscal Year
Never choose a date close to the end of the fiscal year. There is a chance that accounting may create forecasts of sales for what you are building. Once they make these forecasts, then it will be much more difficult to get the date modified.The end of fiscal year also causes problems due to vacations. Many companies limit vacation carry over, forcing people to burn up their vacation before year end.
Christmas
The last two weeks of December and first week of January is a bad time to try to get anything done. People have a lot going on in their lives, and are not as focused on work as they typically are. Even if your direct staff plans around the release, the accompanying staff will not. There is nothing more difficult than trying to get people around Christmas time. Also, executives will be off as well, so this will make it difficult to get sign off on a product delay.End of the Summer
People will take vacation in the summer, and even if you plan it so that each person is covered off during their vacation, it will result in pain. Shipping time is when you need all of your bench strength, and not people doing two jobs while covering someone.
In a future post I’ll try to address which date to choose.
The developers will rise up
For those of you not from a technical background, dealing with technical people may seem a bit alien. This is the story of what happened when Cara (who reported into the sales organization) attempted to run a technical project.
I don’t recall Cara’s title, but she was the interface between the customer and the development team. We were working on a customization of our product for the customer, so there was a to be a lot of communications between her and the team. During the initial phase, one of our more cranky engineers was assigned to complete the project. Cara was new, we didn’t know anything about her. Mr. Cranky was in his heart a decent guy, but did not suffer idiots. Within two days, Mr. Cranky was complaining about Cara. We were not surprised about this, as Mr. Cranky complained a fair amount. About a week in, Mr. Cranky told his manager that he refused to work with her and demanded to be put on another project. No one in the development team was surprised.
Over the course of the next two months, it seemed as if the engineers were added to the project than left. After half of the engineers unsuccessfully tried to work with Cara, several of them got together for a beer in the kitchen one evening to discuss Cara. They decided that Cara had to go. Several of the senior engineers approach the VP of development and told him of the problems with Cara and that the team was refusing to work with her. The VP listened to the issues and told the engineers he would escalate it to the executives.
After the escalation, they tried using sales engineers for the project. The sales engineers were unable to work with her either. The project ended up failing.
Cara considered engineers as interchange widgets and that engineers were a cast of “untouchables”. Her disdain for engineering contributed to her failure, but was not the root case. The two main problems which made it impossible for her project to succeed were a lack of understanding and a refusal to communicate.
The problem was that Cara could not communicate the proper requirements to the team. She would communicate requirements which were completely in left field. The requirements were obviously not something any customer would want. Development asked her for clarifications, and she would shout buzzwords at the engineers then return to her office. The development team attempted to get direct access to the customer, but she refused to allow anyone other than herself talk to them.
Cara was a one trick technical pony, she only understood one technical item, and mapped every problem into the one thing she understood. Cara joined our company and was placed on the project immediately. Her previous two companies were in the same domain, with those previous projects all using the one particular technology to solve the problem. Unfortunately, this time the problem (and the solution) were different. Cara didn’t understand the problem the customer was trying to solve, which doomed the project to failure. She could no longer keep spewing buzzwords at the team and get them to build the solution. Cara refused to seek help for herself (or the company) by allowing another person to communicate with the customer, which further contributed to the failure.
Build Systems
I hope someday to see a build system that is held together with more than twine and a prayer.
Developer Configuration
Filed under: Big Company, Crazy, Development, HR, Small Company
In a world where software developers spend 75% of their day at their desk coding, why is it that senior management goes cheap on the equipment? Here in order of importance are the items to provide your developers with a comfortable work environment.
-
Dual Large Monitors
Why is it that asking for two large monitors requires more paper work approval than a trip to Asia? Two large LCD monitors, maybe more, no less.Fast Computer
This may seem stupid, but many companies try to save a couple of hundred dollars when purchasing computers by going with slower computer and less ram. When it takes a long time to compile code, people are more likely to context switch to /. while waiting for it to compile. If it can be compiled quickly, developers are less likely to lose their train of thought.Comfortable Chair
If you are sitting at your desk for the majority of the day, spending the extra 1000$ for a nice chair. A developer once said about his chair, “You can have my Aeron chair when you pry it from my cold dead butt.” Over 1000$ for a chair seems expensive, but over 4 years (1000 working days) it is not that expensive. See Joel on software for his chair ROI calculation for the chair.Easy Meeting Room Access
A meeting room which can be accessed by developers without requiring them to book it ahead of time.
What I did not mention in here was offices. There is a large debate as to whether giving developers offices is better or worse, that will be left as a topic for a future post.
