Microsoft has done it again!
I've been dabbling with C# 6.0 features and I am really liking it. However, Microsoft has made adoption a real problem.
C# 6.0 is only supported in Visual Studio 2015. Ok so far but Visual Studio 2015 will only install on Windows 8 or later.
Gack!
Windows 8 was stillborn and no one wants to install it. Microsoft tried to convert its Windows desktop OS to a tablet OS and made a spectacular mess of it. So much so that they hastily released a Windows 9 (which they called 8.1 so they could offer it as a free upgrade). So dramatically didn't it fix things that they have now also offered Windows 10 as a free upgrade. People still don't want it so they have now taken the rather extreme measure of dramatically shortening the support agreement for Windows 7.
However, the whole mess of convolving the tablet OS with the desktop OS has left everyone afraid. Microsoft is trying to make the upgrade even easier (update is becoming more like a service pack) but many people that have Windows 7 aren't taking the bait.
In my office we are mostly still on Windows 7 and people are not eager to install new Windows versions. A few nice syntactic features in C# 6.0 aren't going to push people over the hump.
So, I've had to abandon C# 6.0 for now. I imagine this experience will be common and that adoption of C# 6.0 will be weaker than it should be.
To fix this Microsoft could decouple VS 2015 from Windows 8 or back port C# 6.0 into VS 2012. Otherwise, they risk losing momentum with what is really a great language and development environment. Come on guys, give us some better options.
Wednesday, 2 December 2015
Use Commit Discipline to Limit Code Entropy
Source control software is a basic tool that we are all familiar with but it is often perceived most importantly as a management tool to associate work with bug/feature tickets and manage deployment to release branches.
It is also a very useful for keeping code clean which can be especially important if you have mission critical code areas.
It is very simple and not particularly time consuming: look at all the differences when committing code and make sure your commit is clean. If your code base is clean you want to keep it that way and to aid troubleshooting of new bugs you want to be able to trace the change history.
One common scenario is that a change has required experimentation and debug logic. Once you finalize an approach you may have remnants of experiments, debugging logic and fragmented logic. Review this code from the perspective of the finalized approach. Ensure it is clean. It is surprising how often I've avoided committing vestiges of the development process.
Keep the granularity of commits as small as possible. It is a great way to focus on the change in context. For example, as part of a new application feature you've added a new method to your Rectangle class. Reviewing and committing the Rectangle change separately creates a focus on the Rectangle class that will help to maintain the intent and overall design of the Rectangle class.
Avoid coupling refactoring and gratuitous changes that obscure differences with functional changes. Implement refactoring and cosmetic changes as a separate commit and note in the commit comment that there are no functional changes. A simple example is moving code around. As a class grows it can help to reorganize the code layout but most source control software sees these moves as differences. If there is an actual difference in the function you have moved it is likely you won't notice it.
It's also a good time to review the area around your change. Are there code comments that are affected by your change? Have you obviated or orphaned existing code or variables?
Keeping mission critical commits clean is a very simple way to keep your mission critical code and its history clean. The second law of thermodynamics applies to all systems, including a software system. All changes will tend to increase entropy (disorder) but we can minimize the disorder by the these simple practices.
You don't have to be as disciplined everywhere but I find that developing this simple discipline where it is most important becomes habit forming and helps improve the quality of all commits.
It is also a very useful for keeping code clean which can be especially important if you have mission critical code areas.
It is very simple and not particularly time consuming: look at all the differences when committing code and make sure your commit is clean. If your code base is clean you want to keep it that way and to aid troubleshooting of new bugs you want to be able to trace the change history.
One common scenario is that a change has required experimentation and debug logic. Once you finalize an approach you may have remnants of experiments, debugging logic and fragmented logic. Review this code from the perspective of the finalized approach. Ensure it is clean. It is surprising how often I've avoided committing vestiges of the development process.
Keep the granularity of commits as small as possible. It is a great way to focus on the change in context. For example, as part of a new application feature you've added a new method to your Rectangle class. Reviewing and committing the Rectangle change separately creates a focus on the Rectangle class that will help to maintain the intent and overall design of the Rectangle class.
Avoid coupling refactoring and gratuitous changes that obscure differences with functional changes. Implement refactoring and cosmetic changes as a separate commit and note in the commit comment that there are no functional changes. A simple example is moving code around. As a class grows it can help to reorganize the code layout but most source control software sees these moves as differences. If there is an actual difference in the function you have moved it is likely you won't notice it.
It's also a good time to review the area around your change. Are there code comments that are affected by your change? Have you obviated or orphaned existing code or variables?
Keeping mission critical commits clean is a very simple way to keep your mission critical code and its history clean. The second law of thermodynamics applies to all systems, including a software system. All changes will tend to increase entropy (disorder) but we can minimize the disorder by the these simple practices.
You don't have to be as disciplined everywhere but I find that developing this simple discipline where it is most important becomes habit forming and helps improve the quality of all commits.
Friday, 20 November 2015
Being on the Wrong Side of an Arrogant Tech Idealist OR How To Be A Hired Gun.
I had a miserable experience with a new hire, a self professed object oriented guru. I wasn't involved in bringing this fellow in. An odd situation but I approached it with an open mind. A fresh pair of eyes can be a good thing. It didn't need to be a miserable experience.
It made me think about how one should go about evangelizing change. I've been on the other side of this fence but I've never seen how much the approach can dictate the outcome.
The first problem was that management gave this person carte blanche. Not a good idea if you want to avoid conflict. However, the guy should have known better than to abuse this privilege so that doesn't change the lesson of this post.
First rule. Be sensitive and diplomatic. Don't be shocked or indignant by anything you see. Small companies have many skeletons in the closet. That isn't necessarily a reflection on the people, the very people that did the very work you are critiquing. If you put people off they won''t want to help you.
Listen. People know a lot more about the technical and cultural challenges than you do. Especially listen for consensus and push back. Focus initially on issues that have consensus. Build rapport by building on consensus. Defer sensitive issues until you have built trust and can explore the reasons for the push back.
Don't talk down. Some of the things you advise may already be well understood. Constraints may have dictated the course of events, not knowledge. Also, people may want to learn new practices but that will dry up fast if you talk down to them.
Be pragmatic. This blog is about software development in small companies. There is not much room for idealism in a small company. Demonstrating pragmatism will earn you respect. Revealing idealism or dogmatism is a sure way to turn people off.
Contribute. Do a feature. Fix a bug. There's no better way to learn about the organization and earn other programmer's respect.
Compartmentalize. Practical examples will be necessary but be selective when demonstrating or applying your recommendations. Don't start out by refactoring everything you touch. Instead, focus your demonstrations on your own contributions or pick a specific area in the system. Look for some level of acceptance before expanding your scope.
Be frank. Don't be afraid to admit that there will be some pain. No pain, no gain. Change always has a cost.
Be firm. Don't sit on the fence. If you decide to go a certain direction, go.
Pick good demonstrations. Make sure there is a tangible benefit. Remember, you are dealing with pragmatic people. If practical demonstrations are not easy to understand and compelling you may not get buy in.
Respect current practices. For example, if there are code reviews, offer your code for review. Don't set yourself above the status quo.
Pace yourself. Oversaturating people will turn them off. Think evolutionary rather than revolutionary - revolutions can be bloody and we're trying to avoid that. At the same time, avoid going too slow or people won't pay attention.
Know when to stop. Keep the costs and benefits in mind. Even if you've been successful so far, don't forget that you can still lose people if you forget to be pragmatic.
The approach might be different if you are a consultant.Then you might have a much shorter time frame. However, the playing field is the same. If you want your recommendations to be followed through you still need to demonstrate value and earn respect.
It made me think about how one should go about evangelizing change. I've been on the other side of this fence but I've never seen how much the approach can dictate the outcome.
The first problem was that management gave this person carte blanche. Not a good idea if you want to avoid conflict. However, the guy should have known better than to abuse this privilege so that doesn't change the lesson of this post.
First rule. Be sensitive and diplomatic. Don't be shocked or indignant by anything you see. Small companies have many skeletons in the closet. That isn't necessarily a reflection on the people, the very people that did the very work you are critiquing. If you put people off they won''t want to help you.
Listen. People know a lot more about the technical and cultural challenges than you do. Especially listen for consensus and push back. Focus initially on issues that have consensus. Build rapport by building on consensus. Defer sensitive issues until you have built trust and can explore the reasons for the push back.
Don't talk down. Some of the things you advise may already be well understood. Constraints may have dictated the course of events, not knowledge. Also, people may want to learn new practices but that will dry up fast if you talk down to them.
Be pragmatic. This blog is about software development in small companies. There is not much room for idealism in a small company. Demonstrating pragmatism will earn you respect. Revealing idealism or dogmatism is a sure way to turn people off.
Contribute. Do a feature. Fix a bug. There's no better way to learn about the organization and earn other programmer's respect.
Compartmentalize. Practical examples will be necessary but be selective when demonstrating or applying your recommendations. Don't start out by refactoring everything you touch. Instead, focus your demonstrations on your own contributions or pick a specific area in the system. Look for some level of acceptance before expanding your scope.
Be frank. Don't be afraid to admit that there will be some pain. No pain, no gain. Change always has a cost.
Be firm. Don't sit on the fence. If you decide to go a certain direction, go.
Pick good demonstrations. Make sure there is a tangible benefit. Remember, you are dealing with pragmatic people. If practical demonstrations are not easy to understand and compelling you may not get buy in.
Respect current practices. For example, if there are code reviews, offer your code for review. Don't set yourself above the status quo.
Pace yourself. Oversaturating people will turn them off. Think evolutionary rather than revolutionary - revolutions can be bloody and we're trying to avoid that. At the same time, avoid going too slow or people won't pay attention.
Know when to stop. Keep the costs and benefits in mind. Even if you've been successful so far, don't forget that you can still lose people if you forget to be pragmatic.
The approach might be different if you are a consultant.Then you might have a much shorter time frame. However, the playing field is the same. If you want your recommendations to be followed through you still need to demonstrate value and earn respect.
Monday, 9 November 2015
Find Out What People Find Rewarding
Job satisfaction is critical to employee retention and productivity but companies often misunderstand what people find satisfying. There isn't a simple answer because people are different so it is very important to understand your people.
One thing for sure is that while money can be a factor in retention, it is not a very good source of job satisfaction. In a frustrating environment, you might hear a common cliche, "Oh well. Another day, another dollar." If you hear that, you are in trouble. Money may be some consolation when you have had a crummy day but it is a meager consolation.
There is a dramatic variance in productivity. People can be many times more productive when they are motivated and satisfied than otherwise. It can really pay to understand what gives people satisfaction.
Junior and senior people have different needs. The needs may be similar but the scope will vary. Senior engineers need to see how their work contributes in the big picture and see that their recommendations and designs have visibility. Junior people need to see how their work fits into the part of the system they are working on and that their feature/piece is appreciated.
There are some common factors in job satisfaction and dissatisfaction:
One thing for sure is that while money can be a factor in retention, it is not a very good source of job satisfaction. In a frustrating environment, you might hear a common cliche, "Oh well. Another day, another dollar." If you hear that, you are in trouble. Money may be some consolation when you have had a crummy day but it is a meager consolation.
There is a dramatic variance in productivity. People can be many times more productive when they are motivated and satisfied than otherwise. It can really pay to understand what gives people satisfaction.
Junior and senior people have different needs. The needs may be similar but the scope will vary. Senior engineers need to see how their work contributes in the big picture and see that their recommendations and designs have visibility. Junior people need to see how their work fits into the part of the system they are working on and that their feature/piece is appreciated.
There are some common factors in job satisfaction and dissatisfaction:
- challenge, coolness
- visibility, appreciation.
- appropriate forms of support
- quality
- pain level
There are some common scenarios that can be satisfying or dissatisfying depending on how they are handled. Almost everything management does has some effect on individual people's job satisfaction and motivation. Be aware of the effect of your management decisions and style.
Challenge
Most software involves a certain degree of tedium. People who have significant responsibility for maintenance work, backwards compatibility, etc. may have a high degree of tedium. Don't forget to share out some of the cool work to all people. At least give them a chance to be involved when there is new/cool work. Don't get caught in the trap of thinking that a person is too busy and that you can't afford to have them work on something cool.
Avoid a hero culture when a select few get all of the cool work and visible appreciation. Instead, create a culture where everyone contributes and gets visible appreciation.
Avoid a "give it to the Co-op" culture where work that would be interesting to a senior person is given to an overly junior person, especially when you will later expect the more senior people to live with and possibly maintain the thing. Instead, give the Co-op to the senior person to direct and mentor.
One of the best experiences for junior people is to work with more senior people. You can easily spoil them by giving them a taste for glory too early.
Appreciate
Show appreciation at the level where the work is done. Regularly. As immediately as possible. If the only visible appreciation given is the open e-mail from the CEO congratulating engineering on a project that just achieved a General Availability release milestone, don't be surprised if this fails to make people feel appreciated. It's too little, too late. It could be months to many months after the work was done.
Appreciation should be based on tangible evidence that the work is complete. A unit test, integration test or demonstration. Don't be arbitrarily appreciative or you will encourage poor work.
Recognize initiative. If someone shows initiative in a valuable area, give them visible appreciation, give them a role moving forward. A financial bonus for initiative can be a very much appreciated and a better use of money than a raise.
Don't bypass people. If they've had a role in the past, involve them in the future.
Support
Listen to what your best people need. Be careful not to intrusively, forcefully help them, like taking a part they've done good work on and give it to someone else because you think they are too busy. Talk to them first. Find out what they want.
If people ask for help, listen.
Quality
Have a quality agenda if possible. Allow people to feel proud of the product and their contribution to it.
Pain Points
Develop a good development culture. Recognize competency and allow your best people to work with your best people.
Some development activities are painful. Don't try to hide necessary evils but do try to minimize any unnecessary pain points. Avoid ADHD behavior, militant project management, finger pointing, etc.
Wednesday, 4 November 2015
Emergent Challenges
I recently read "Prey" by Michael Crichton which is an exciting, easy read that explores the surface of nano-tech programming gone wrong.
A key element of the story is that high level goals and behaviors are too sophisticated to program into such simple devices. A programmer devises individual behaviors that interact to result in a desired collective, overall, emergent behavior. This is also how insects work. No individual bee knows how to build a hive. It is the outcome of a collection of primitive individual behaviors.
Where it goes wrong is in how difficult it is to predict and control emergent behaviors.
This idea of emergent behavior exists in more complex systems. In fact, I imagine it exists in every system. This article is about how it exists in technology projects in a real way that can affect quality, time to market and success or failure.
Pointers are a powerful feature in C but so many problems emerge from programming using pointers that modern languages like Java and C# have completely abstracted pointers and object life cycles out of the language and moved them into a virtual machine with automatic garbage collection. A solution was too dependent on garbage collection to be solved with pointers. Solving the emergent pointer problems of C required a paradigm shift.
Sometimes emergent problems could be solved in the original domain but laziness and new features often drive new paradigms, e.g. Microsoft's shift from WinForms to WPF. Although it is a paradigm shift in some ways I don't think the advantages would be compelling to most small companies. What Microsoft doesn't tell you is that, while WPF may be the answer to some of the problems that emerged from WinForms, a whole new set of emerging problems will be caused by WPF. Here is one of the most sensible things I've seen written about WPF - http://stackoverflow.com/a/75387.
Every new technology will have new emergent challenges. Don't forget this simple fact when tempted to switch to a new technology. The real problem is that a new technology is new to everyone and the problems that are going to emerge aren't yet known. Also, the evangelists are biased. Don't expect them to caution you about realities. Think about how aggressively Microsoft evangelized COM. Where is it now?
Even large scale systems have emergent behaviors. For instance, the obsession with copyright in the western world has driven a lot of innovation into the far east. We arm patent owners with trivial or self-evident patents and powerful legal leverage that prevents derivative innovation. The emergent result is to empower countries where those patents are not enforceable to innovate and threaten our dominance in a technology.
Another example is the success of personal injury lawsuits in American society. Bell used to be a prominent motorcycle and bicycle helmet company. Because they were American they were the successful target of anyone in the western world that wanted to sue them after personal injury because they were wearing a Bell helmet. The result was to stifle the helmet industry in North America and create a vacuum which was filled in the Pacific Rim where personal injury lawsuits could not easily get traction. For years the motorcycle industry has been dominated by Arai, Shoie, HJC, etc.
Be wary of new paradigms. Even if the end result is compelling, the transition will almost certainly cost more than anticipated, take longer the estimated and present a new set of problems that will take further time before new practices are established and incorporated in your development environment.
My best advice is to be aware of new techonologies and to experiment with them so that you can judge the cost/benefit issues for your own situation. When you want to transition, do it in a series of phases that mitigates the cost, learning curve and risk to delivery dates for your next few releases.
A key element of the story is that high level goals and behaviors are too sophisticated to program into such simple devices. A programmer devises individual behaviors that interact to result in a desired collective, overall, emergent behavior. This is also how insects work. No individual bee knows how to build a hive. It is the outcome of a collection of primitive individual behaviors.
Where it goes wrong is in how difficult it is to predict and control emergent behaviors.
This idea of emergent behavior exists in more complex systems. In fact, I imagine it exists in every system. This article is about how it exists in technology projects in a real way that can affect quality, time to market and success or failure.
Pointers are a powerful feature in C but so many problems emerge from programming using pointers that modern languages like Java and C# have completely abstracted pointers and object life cycles out of the language and moved them into a virtual machine with automatic garbage collection. A solution was too dependent on garbage collection to be solved with pointers. Solving the emergent pointer problems of C required a paradigm shift.
Sometimes emergent problems could be solved in the original domain but laziness and new features often drive new paradigms, e.g. Microsoft's shift from WinForms to WPF. Although it is a paradigm shift in some ways I don't think the advantages would be compelling to most small companies. What Microsoft doesn't tell you is that, while WPF may be the answer to some of the problems that emerged from WinForms, a whole new set of emerging problems will be caused by WPF. Here is one of the most sensible things I've seen written about WPF - http://stackoverflow.com/a/75387.
Every new technology will have new emergent challenges. Don't forget this simple fact when tempted to switch to a new technology. The real problem is that a new technology is new to everyone and the problems that are going to emerge aren't yet known. Also, the evangelists are biased. Don't expect them to caution you about realities. Think about how aggressively Microsoft evangelized COM. Where is it now?
Even large scale systems have emergent behaviors. For instance, the obsession with copyright in the western world has driven a lot of innovation into the far east. We arm patent owners with trivial or self-evident patents and powerful legal leverage that prevents derivative innovation. The emergent result is to empower countries where those patents are not enforceable to innovate and threaten our dominance in a technology.
Another example is the success of personal injury lawsuits in American society. Bell used to be a prominent motorcycle and bicycle helmet company. Because they were American they were the successful target of anyone in the western world that wanted to sue them after personal injury because they were wearing a Bell helmet. The result was to stifle the helmet industry in North America and create a vacuum which was filled in the Pacific Rim where personal injury lawsuits could not easily get traction. For years the motorcycle industry has been dominated by Arai, Shoie, HJC, etc.
Be wary of new paradigms. Even if the end result is compelling, the transition will almost certainly cost more than anticipated, take longer the estimated and present a new set of problems that will take further time before new practices are established and incorporated in your development environment.
My best advice is to be aware of new techonologies and to experiment with them so that you can judge the cost/benefit issues for your own situation. When you want to transition, do it in a series of phases that mitigates the cost, learning curve and risk to delivery dates for your next few releases.
Friday, 2 October 2015
Lessons Learned and Not Learned
A start up takes many expediencies. As it starts to grow and especially when it brings in new people in management, product management and operations roles there will be need for change. I have seen many companies review operations and tabulate lessons learned. In theory this is a good exercise but there are several pitfalls.
Be respectful to the people that got you to where you are today. They are the doers. Be careful when introspecting not to demoralize and demotivate the people that actually know how to get things done. Don't talk about the current state and past actions negatively. If you believe that your problem is competency you need to fix that before doing any kind of reviews or post mortems.
Consider that the lessons learned might be wishful thinking. Don't encourage wishful thinking and whining. Don't legitimize it. A good sign that your lessons learned are whining is that they are symptomatic of some underlying issue, like limited resources.
Don't get stuck in this introspective, critical mode. I've seen companies perpetually talking about lessons learned. For years. If you embark on self analysis, give it a specific time frame and make specific conclusions and actions and then stop.
Don't make a laundry list. If you have more than 5 lessons learned there is something wrong. You might notice many issues but filter that down to no more than a handful of lessons.
Don't undermine your strengths. What some people consider a weakness might be the result of a very important strength. Fixing a minor weakness might have serious side effects. Be careful not to lose the spark that got you where you are today.
Be wary of solutions. Every solution makes the environment more complicated. Every complication adds new problems. Especially be wary of adding controls and processes. They are often more difficult to do well than they appear.
Be wary of silver bullets. Real world problems rarely have trivial solutions.
Be balanced. Post mortems are often top down - managers, department heads. Nearly all of these people have the same perspective. Often your engineers know the root causes and best practices to address the real problems that you face. If your lessons learned are all processes, controls, etc. then there is a good chance that your analysis is one sided.
Some Constructive Ideas for High Level Corporate/Departmental Reviews
Lessons learned are often symptoms. This is one of the biggest pitfalls. Patching symptoms can be very tedious and expensive because they tend to pop up everywhere. Make sure that your lessons learned are the right lessons. Try to understand the root causes of perceived problems. Addressing one root cause will likely address many symptomatic problems. Avoid the pitfall of essential lessons NOT learned.Be respectful to the people that got you to where you are today. They are the doers. Be careful when introspecting not to demoralize and demotivate the people that actually know how to get things done. Don't talk about the current state and past actions negatively. If you believe that your problem is competency you need to fix that before doing any kind of reviews or post mortems.
Consider that the lessons learned might be wishful thinking. Don't encourage wishful thinking and whining. Don't legitimize it. A good sign that your lessons learned are whining is that they are symptomatic of some underlying issue, like limited resources.
Don't get stuck in this introspective, critical mode. I've seen companies perpetually talking about lessons learned. For years. If you embark on self analysis, give it a specific time frame and make specific conclusions and actions and then stop.
Don't make a laundry list. If you have more than 5 lessons learned there is something wrong. You might notice many issues but filter that down to no more than a handful of lessons.
Don't undermine your strengths. What some people consider a weakness might be the result of a very important strength. Fixing a minor weakness might have serious side effects. Be careful not to lose the spark that got you where you are today.
Be wary of solutions. Every solution makes the environment more complicated. Every complication adds new problems. Especially be wary of adding controls and processes. They are often more difficult to do well than they appear.
Be wary of silver bullets. Real world problems rarely have trivial solutions.
Be balanced. Post mortems are often top down - managers, department heads. Nearly all of these people have the same perspective. Often your engineers know the root causes and best practices to address the real problems that you face. If your lessons learned are all processes, controls, etc. then there is a good chance that your analysis is one sided.
Seek Closure
Closure is surprisingly difficult to achieve. Every software project has many details that need to be implemented, tested and then rolled out. Meanwhile, market pressures are driving the product in new directions with bugs and new features.
It's not just software. When I do a home project, I tend to procrastinate and waffle on the last 10%. Psychologically, that last 10% is often the hardest part. I have a bathroom that is still missing a piece of trim from a reno I did 3 years ago.
We also often hear about emotional closure. After breakup we need to move on with our lives. There are always loose ends and baggage to deal with. Without closure we aren't moving forward.
A new product or feature has goals which will never be 100% met. There are always loose ends. The reality is that we can't be perfectionists There will be details that can't be cleared up in a timely fashion. It takes a conscious effort to tie them off. Otherwise the project enters a form of limbo - some stuff is not quite finished but at the same time isn't important enough to get finished.
Closure requires a conscious effort, discipline and determination. It doesn't happen organically or accidentally.
The first principle is to
The second principle is to
The third principle is to
As always, there are going to be exceptions but you need discipline and to be prepared to take a hard line on these three basic principles at times.
Stage 1. Planning
During the next two weeks you find some bugs during verification that need to be fixed. Bob is sick for a few days. Some new market information suggests that one of the new features in the release might need to be changed. Now it seems that it will be at least another week.
During that week you get some closure on the original scope but Bob learns that his estimate was incorrect. In addition to the sick time he will probably need another week.
During that week there is an additional push from marketing to change feature X they were so hot about. Bob gets his feature done but no one thought about how to verify it. The verification team does some ad hoc tests but engineering management is concerned that more testing is needed. There is a meeting to discuss dropping the new feature but the feeling is that you are very close and it will make a customer happy. The verification team is asked to do some more comprehensive testing.
After the meeting sales calls down to say that a hot new prospect that is evaluating the product will make a big order if you can do one little thing. Joe is available and can do it in a couple days which won't affect the schedule. The verification team reports that they have found what may be a serious problem in one of the original, key features of the release.
...
You get the idea. Each change at this stage risks the ball game. The more time that goes on, the more opportunity and pressure to make more changes. If this becomes a pattern, people don't take schedules seriously and focus becomes increasingly difficult.
Defend. Someone will always be prepared to argue for some new feature. Creep always has proponents. There needs to be someone that is prepared to argue for the feature to not be included. An effective solution is to require at least three key people to agree to a scope change.
Prioritize. Increase the priority of closure the closer you get to milestone completion.
Be pragmatic as you approach milestone completion. If you have a difficult problem that is holding up a milestone, consider pushing it out or splitting it up and pushing out part of it. Review all remaining tasks and their importance. Streamline and focus the review. Make P1 or P2 bugs mandatory, P3 defer-able with discussion, P4 or P5 auto defer-able.
Be disciplined. If someone checks in a change that wasn't in scope, back it out, especially near milestone completion. It doesn't matter if it is a nice to have. Put it in the next milestone. Create a culture where people know better.
Branch ad hoc requirements. If you have a customer that needs something fast, do it on a branch for that customer only and merge it in the next milestone.
Be mature. If you find a new bug, resist the temptation to fix it right away. If it is a legacy issue don't even entertain a scope change - if customers already have a release that contains it and they haven't noticed yet then there's a good chance they won't notice this time either.
Use a tool to associate tasks with milestones. Use the 'fix version' or 'milestone' field. The unresolved tasks are the remaining development scope. Close issues after they are verified. The resolved tasks are the remaining verification scope. Status is readily available in real time - just query the open issues in the milestone.
Use a triage process. Only a triage team/individual should be able to assign an issue to a milestone. Make your triage team your first line of defense against creep - by default new bugs should not be triaged into the current release
There are always exceptions to the rule. You want to make creep decisions difficult enough that they are taken seriously. The proof is in the pudding - follow these principles and closure will become a regular event. It is a healthy, liberating pattern.
It's not just software. When I do a home project, I tend to procrastinate and waffle on the last 10%. Psychologically, that last 10% is often the hardest part. I have a bathroom that is still missing a piece of trim from a reno I did 3 years ago.
We also often hear about emotional closure. After breakup we need to move on with our lives. There are always loose ends and baggage to deal with. Without closure we aren't moving forward.
A new product or feature has goals which will never be 100% met. There are always loose ends. The reality is that we can't be perfectionists There will be details that can't be cleared up in a timely fashion. It takes a conscious effort to tie them off. Otherwise the project enters a form of limbo - some stuff is not quite finished but at the same time isn't important enough to get finished.
Closure requires a conscious effort, discipline and determination. It doesn't happen organically or accidentally.
Principles
We need to be able to make decisions and stick with them. It isn't easy. It takes a few basic principles, a concerted effort and a pragmatic attitude.The first principle is to
Bundle activities into milestones and manage the milestone, not the individual issues.Seek closure for the milestone, rather than continually trying to get a grip on a chaotic and changing set of unqualified individual issues. A concrete milestone gives you a means to focus.
The second principle is to
Once the scope is agreed, don't let anything else into the milestone.Creep is a basic force of the universe. Individual tasks tend to grow in scope. New features will be wanted. Creep is the enemy.
The third principle is to
Focus people on the milestone. Closure of the milestone depends 100% on closure of the individual issues. Lack of focus and competing priorities are another enemy.That trim in my bathroom would probably never be finished if my wife didn't nag me. It's basic human nature. This is where a project manager can be very useful.
As always, there are going to be exceptions but you need discipline and to be prepared to take a hard line on these three basic principles at times.
The Basic Process
The process is preciously simple.Stage 1. Planning
- Consider your goal and determine the contents of the milestone.
- Estimate a reasonable completion date, or requirement for a market opportunity.
- Are you being greedy? Try to trim the milestone.
Stage 2: Execution
- Resolve issues in priority order. The temptation may be to knock down some of the easy issues first. Don't do that! Avoid back end loading your milestone with all of the hardest issues.
- Verify the issues as early as possible. Avoid back end loading your milestone with all of the hardest testing activities.
- Manage creep. Don't just watch it happen.
- Nag. Make sure that people are working on closure.
- Be practical. The easiest way to get closure is to avoid creep and move outstanding issues to the next milestone.
An Illustration
You are in the late stages of development for a software release but there are still some tasks to complete and a few weeks of calendar time left. It's been some time since the last software release and there's pressure from a customer. The temptation is real and you add a few more tasks. Bob isn't on the critical path and he can do the work without impacting the schedule.During the next two weeks you find some bugs during verification that need to be fixed. Bob is sick for a few days. Some new market information suggests that one of the new features in the release might need to be changed. Now it seems that it will be at least another week.
During that week you get some closure on the original scope but Bob learns that his estimate was incorrect. In addition to the sick time he will probably need another week.
During that week there is an additional push from marketing to change feature X they were so hot about. Bob gets his feature done but no one thought about how to verify it. The verification team does some ad hoc tests but engineering management is concerned that more testing is needed. There is a meeting to discuss dropping the new feature but the feeling is that you are very close and it will make a customer happy. The verification team is asked to do some more comprehensive testing.
After the meeting sales calls down to say that a hot new prospect that is evaluating the product will make a big order if you can do one little thing. Joe is available and can do it in a couple days which won't affect the schedule. The verification team reports that they have found what may be a serious problem in one of the original, key features of the release.
...
You get the idea. Each change at this stage risks the ball game. The more time that goes on, the more opportunity and pressure to make more changes. If this becomes a pattern, people don't take schedules seriously and focus becomes increasingly difficult.
Making the Hard Part Easier
How do you do this? Here are some specific techniques that anyone can use successfully, regardless of the size of your company.
Prioritize. Increase the priority of closure the closer you get to milestone completion.
Be pragmatic as you approach milestone completion. If you have a difficult problem that is holding up a milestone, consider pushing it out or splitting it up and pushing out part of it. Review all remaining tasks and their importance. Streamline and focus the review. Make P1 or P2 bugs mandatory, P3 defer-able with discussion, P4 or P5 auto defer-able.
Be disciplined. If someone checks in a change that wasn't in scope, back it out, especially near milestone completion. It doesn't matter if it is a nice to have. Put it in the next milestone. Create a culture where people know better.
Branch ad hoc requirements. If you have a customer that needs something fast, do it on a branch for that customer only and merge it in the next milestone.
Be mature. If you find a new bug, resist the temptation to fix it right away. If it is a legacy issue don't even entertain a scope change - if customers already have a release that contains it and they haven't noticed yet then there's a good chance they won't notice this time either.
Use a tool to associate tasks with milestones. Use the 'fix version' or 'milestone' field. The unresolved tasks are the remaining development scope. Close issues after they are verified. The resolved tasks are the remaining verification scope. Status is readily available in real time - just query the open issues in the milestone.
Use a triage process. Only a triage team/individual should be able to assign an issue to a milestone. Make your triage team your first line of defense against creep - by default new bugs should not be triaged into the current release
There are always exceptions to the rule. You want to make creep decisions difficult enough that they are taken seriously. The proof is in the pudding - follow these principles and closure will become a regular event. It is a healthy, liberating pattern.
Subscribe to:
Posts (Atom)