Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Do you actively manage technical debt debt on your software development projects and if so, how do you do it?
One aspect of managing technical debt is in convincing non-technical managers that you need time allocated for refactoring and bug fixing.
Here's an article with specific suggestions on how to do that.
On our teams we actively manage technical debt. We do Scrum, so we spawn a technical debt card for either the current iteration or the next iteration depending on the estimate and our remaining sprint capacity and they get prioritized just like features and bug cards do. We also manage larger, cross-team debt items by having a cross-team backlog of technical debt that we prioritize and inject into each Scrum team during their sprint planning.
I think it's important to schedule time for dealing technical debt if you are trying to make up for old sins, but I also think you should not make this a habit. Once you clean up the mess you should avoid putting your project into more debt, unless you have good reasons for doing so.
Actively managing it like Mike suggests seems like the most reasonable approach, but I think it's very important to make it clear (to your team) that you should not schedule time or plan for refactoring in the long run.
Refactoring should be a natural part of writing code, and thus should be included in your other estimates and plans, and not be treated as a separate activity—unless you have to, i.e for "historical" reasons or because you consciously decided to implement something a given way and then re-implement it later.
What you do is create a culture where technical debt is not acceptable unless in extreme cases. Much like people who only pay cash and use credit only as an absolute last resort.
If I really need to pile up technical debt, because I need to release something NOW, I file a critical bug about it, so it gets highest priority. But it is only for extreme situations (the client is jumping up and down, the wife is looking for a dingbat etc.).
It depends a lot on the product. When I worked in a field where our code had to be outside-audited it was a planned part of our sprint. PM just asked development what area needed refactoring and it was put in the plan. That's not to say you wouldn't fix the code in the area you were working on, but you wouldn't devote a day to rewriting a mangled chunk of code that worked. Now I'm working in scrum and developers just do it as they work. My impression is that about the same amount of time goes into refactoring work, either way.
I agree with Anders. If you have to set up systems for managing technical debt, that means you're still adding it. Stop going into debt in the first place by upgrading your definition of "done".
This does mean that "indebted" modules will be harder to work through. Developers should be aware of this and assign more story points so that they leave things "done" in their wake.
If you're late into release cycle you don't want to change the code base too much. This means there will always be some technical debt. I usually write FIXME:s for the changes that are suboptimal and then I take care of them before I start to implement features for the next release.
Java Posse have covered the management of Technical Debt recently which looks very comprehensive.
On the projects I have been involved so far, some technical debt has been "paid" (managed) only at the beginning of new phases of the projects, i.e. after "big releases" or milestones.
A very important aspect about technical debt is that it not only involves developers but management as well. In that sense, I am aware that the best way to deal with it, is to make it visible to "non-technical project stakeholders" who might allocate time and resources to manage the technical debt once they understand its implications.
This article discusses several types of technical debt, which ones might be healthy, and specially how to manage and track the technical debt load.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I lead a team of six programmers, and we are presently implementing a number of agile development practices. I'm very interested in Scrum, however it seems to assume that your project will have multiple developers. Most of my projects are smaller, and involve a single developer. We run 3 or 4 such projects in parrallel at any time.
From reading Schwaber, a lot of the benefit of Scrum seems to derive from teams self-organising to achieve a complex task. If you have a single developer doing all the work, will Scrum deliver much value?
Scrum might be more than you need as a single developer, but if you have a stake holder and a QA person then Scrum can still be helpful. Remember they are apart of your team, and should be at your standups to trade information with the team.
If you are truly alone there are other agile practices that might make more sense to you. For example, Kanban might be a better fit. You don't have iteration overhead, retros, sprint planning, etc. You just have a backlog that you pull tasks from. This works well as a way to organize your work, allows stake holders to adjust priorities, and works well for a single developer or small team where you can break up work without a lot of need to synchronize between developers. Maybe you have a product built that only has small features that doesn't need a lot of architecture being built to support new features. Or lots of small projects that are independent say for advertising firms, etc.
The single most important benefit of Scrum that is there even if there is just one developer is not the daily sync (meeting), but rather the limitation on context switches. While working in sprints this single developer can concentrate on given stories within his (presumably short) sprint knowing he won't be interrupted or pushed to do something else before finishing this.
Less context switching == less waste == more productivity.
BTW - Kanban offers less overhead than Scrum, but it is easier to circumvent and force developer to context switch. This can be a benefit but can easily become a problem too.
I think that the value you may get can come from scrum or other agile concepts.
For example, instead of a weird standup meeting, have the one developer tell you why he has taken x desicion for the y task. You may or may not be able to suggest things (depends on your background as a developer I guess), but the fact that the developer is hearing his own explanation might be useful for finding bugs or dead-end reasonings.
As a professor of mine once commented on asking yourself a question aloud: "If you ask the universe for an answer, it will give you one"
While, as others have pointed out, the daily standup may be weird, there's still value for an individual developer in adopting a scrum-'like' process.
Timeboxed, potentially releasable, iterations and a stack-ranked backlog can only help an individual developer keep focused on actually getting something done instead of endlessly ratholing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
How to deal with a project manager that imposes really tight deadlines but with a day or so before the deadline brings in new features and spec changes to implement, with another tight deadline.
The worst thing about this is that most of the new stuff leads to major rewriting of the existing code, as previously implemented business rules are no longer applicable or "gain" strange corner cases that need to be treated separately.
It seems that no matter how hard we try to make the system extensible, there always are things that come up literally in the last moment and need to be implemented and supported quickly.
How could I deal with such a situation? It's being really demoralizing and one colleague has already quit the team.
It's true that no matter what you do, you're human and you'll make mistakes or miss things. That said, regular changes to your requirements are most often the result of either poor requirements or poor develoment process, or both.
Some Design Up Front?
Business analysis is regularly given the short shrift by developers, project managers, etc. Most devs just want to start hacking away on day 1, and most PMs love to let them: "Wow, we can move from the project initiation phase to the construction phase in 1 day without any of that ridiculous business analysis stuff taking up time! That'll look great for completion bonuses!" But remember that the PM's primary job is to keep the project under control (on time and on budget) ...not necessarily to make users happy and certainly not to make developers happy. That's not to say they are totally heartless; good PMs will achieve their goals by enforcing scope control and fostering communication, both of which are helpful.
But taking the time to really think about what's needed and stepping through possible scenarios can make a serious difference in the issues you're dealing with.
If you have made an effort to do thorough business analysis and you're still ending up with last minute changes, then perhaps your problem is another classic challenge: disengaged users. Your subject matter experts are your top weapon in dealing with and identifying those corner cases. If you have users that are not engaged in the analysis process, get better subject matter experts.
It's also possible users are disengaged because they are too busy doing their regular work. In that case it's a management issue and they need to be given instructions that project participation is part of their jobs; that's hard sometimes because often the same management that told you to "get it done yesterday" is the same group of knuckleheads that is expecting the project to happen magically with no hiccups and without any resources (they are common in that they don't understand the complexities of custom software development and assume it is easy). If management is clueless and won't change...well, you have to either work overtime and deal with the issues you've described, or get a new job.
Can Agile Help?
It'd sure be nice if your users would tell you about those corner cases earlier rather than later, right? This is related to what Toby Hede discussed in his post. Perhaps a methodology that gets the software in front of the users as soon as possible, even in an unpolished state, can trigger feedback sooner. That was one of the inspirations for all the agile concepts. The creators were tired of dealing with the issues you describe and they also realized that if management and users weren't going to change, then maybe the development could. It's still development, but there's an emphasis on getting early feedback through a variety of techniques (have subject matter experts co-located with the dev team, getting rough prototypes into user hands sooner, pair programming to captalize on developer experience, and lots more). All this is because it's understood we're human and we're going to miss things.
Finally, you mention you're trying to make the system extensible to help with the rapid changes, but how? Are you separating presentation logic from business logic? Are you encapsulating business logic in objects, partitioned appropriately to minimize dependencies and coupling? All of those things are tough to do and can take time to plan and build.
You're not alone, by the way. Lots (maybe all) shops have these challenges.
Don't let them impose the deadline in the first place.
You have 2 options
The PM gives you a list of features and you tell them when it'll be ready.
The PM gives you a list of features and a deadline. You then tell them which features you'll implement in the given time.
If the PM is your manager or has the authority to impose deadlines + number of features, then I'd be looking for a new job. careers.stackoverflow.com
If the PM isn't your manager then you need to get your manager on board and have them give the PM their options from the above list.
This stuff is really challenging to deal with. The real problem here is that you don't actualy have a process.
The answer really depends on the political situation in your organisation and how much eneergy you have to drive change.
In the past I have attempted to introduce process change to several organisations and it has always been a struggle. It is possible, however.
I would have a look around at some methodologies for managing software development. I use and recommend Scrum, for example.
In a situation with rapid change, working on short iterations that have clearly accountable goals can be really helpful. You will probably need to champion and manage your Project Manager, but it sounds like the current "process" is clearly not working, so selling a new process actually becomes easier - you have solid business case for improvement.
A solid process will help you "push-back" on changing requirements. Rapid reactionary change is often a symptom of broader issues in organisational direction and strategy and it is in everyone's interest to fix this problem within the organisation.
This is one of the major challenges you will face as a developer.
One good technique I've used in the past is to ask questions. When you get the specs, find something in them which needs clarification from the final users. This always slows things down, and raises the possibility in managers minds of risks.
Make sure that your project manager knows the risks involved in implementing late changes for a project.
Have you and your team tried discussing about this with the manager himself? That's the first thing you should do.
He might not have that much experience with the development process, hence the constant tight deadlines and very late major changes. I've seen such cases, people who couldn't develop but thought they could do a better job at PM.
From sitting and talking to him there could come out two thing, depending on his personality/professionalism. He'd accept your points and try change the situation for the future or he'll be a smartboy and won't give in a bit, in which case it is worth escalating the situation to a higher level. I don't think there is any company that will happily accept losing developers.
Alternatively, his manager could be all over him. And that's a problem.
If nothing works out, as already suggested, changing the job is a fair thing to do.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I posted this question on Reddit Programming and did not get a single response. So I am hoping that Stack Overflow community will have an opinion.
Have any of you ever been on a software project that had fallen behind, where 'Crashing' or 'Fast-Tracking' the project schedule actually brought the project schedule back on track? I have never seen either of these project management techniques actually work. And all the articles on software development that I have read all state that these 2 techniques do not work and actually pushing the project further behind (for example literature on the Mythical Man Month). So who has seen it work?
Thanks Bill.
I have only ever seen it work once. It was a three or four month long project that was projected to run an extra two months over the original delivery date. The project got fast-tracked and things ended up getting back on track for the release.
...keep in mind though, that was only once. I've been on many more projects where the PM tried to use one of those two methods and they failed miserably and dragged the project out for months beyond already extended date.
It can work. But there's a price to be paid: lower quality (more bugs, less testing) and turnover of burned-out programmers.
And in many cases, a fast-tracked project will both fail to deliver on time and will still pay the full negative price, for the reasons stated in Mythical man-month.
I've seen it work but it's not the norm.
Things I'd want to see before I thought it might be feasible:
1) Staff available with suitable skills and approach. By that I don't mean ".NET programmer", I mean detailed technical skills, business domain skills (so they understand the problem), personality fit and understand the tools and the approach (source control, methodology and so on). This can happen in large companies where there are common tools, standards and knowledge but you need to be sure that they're ticking pretty much all the boxes.
2) Tasks must be nicely divisible. The best situation is where there are whole modules, applications or tasks unstarted and you can put new people on that. It minimises upskilling, additional communication and so on. If you can't separate out what the new people will do you're likely to majorly disrupt the existing team.
3) The whole team must have bought into the approach. If the existing team don't agree that bringing people on board will be right they'll likely fight it and you're doomed.
4) You need to be sure you've addressed why it was running late in the first place. If it was just bad estimates then are you confident the new estimates are good? If it was scope creep have you got the scope and change control in hand now? If it was because the deadline moved, are you sure it won't move again?
If you can't tick all four of those off, it isn't going to work.
Crashing and Fast-Tracking are two very different things...
Fast Tracking is where you take something (tasks or work packages) out of sequence and do it early. This may because of hardware delivery lead times, availability of resources, risk or whatever. So you might do things in parallel where originally you had planned to do it sequentially. I've fast tracked a lot of projects.. and yes it works.
Crashing a project is different in that you typically throw more resources at a problem to get it done quicker... this can be tricky. If it's done as a crisis response it can be painful adding extra people as you are already under the pump. In some situations you just add more problems.
Another alternative to crashing is to reduce scope. This is not always possible, but it should be considered.
With fast tracking or crashing... the sooner you know when you need to make a schedule change the easier to manage. This is why early deadlines are so important, they indicate how the rest of the project will go.
Both of these project management techniques work well to maintain a schedule, but they should be used intelligently by judiciously analyzing the network diagram:
study the variance,
study lead and lags;
decide what suits to your project: ‘Crashing’ or ‘Fast-Tracking’.
There is a software management principle that says adding manpower to a late project makes it later.
That said, as long as the measures taken are sensible it should be ok. Don't expect too much of your staff and provide reasonable incentives and don't take short cuts. It won't make miracles happen but if you're practical and want to push things just that little bit faster it can definitely be done.
When people have a stake in the potential success of something it's amazing how much more effort they're willing to put in.
It depends on what you mean by "work". I don't think I've ever seen it make a way late project deliver on time, if that's what you are asking.
However, I have seen it make way late projects deliver only a bit late. From the fuzzy perspective of management, that might be called "working". I've also seen it significantly lower the customer-based pressure on the company. Some might also call that "working".
Of course the price is rather high. Employees burn out, develop health problems or big problems in their neglected personal lives, etc. All of that has large financial repurcussions to the company. So I doubt the company comes out ahead in the long run. Is that "working"?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have been studying and reading about Scrum in the last few days and reading about Sprint Planning and tasks. One problem that popped into my mind is how to deal with bugs in Scrum. Henrik Kniberg lists some ways of dealing with this issue in his very nice book Scrum and XP from the Trenches :
Product owner prints out the most
high priority Jira items, brings
them to the sprint planning meeting,
and puts them up on the wall
together with the other stories
(thereby implicitly specifying the
priority of these items compared to
the other stories).
Product owner creates stories that refer to Jira
items. For example “Fix the most
critical back office reporting bugs,
Jira-124, Jira- 126, and Jira-180”.
Bug-fixing is considered to be
outside of the sprint, i.e. the team
keeps a low enough focus factor (for
example 50%) to ensure that they
have time to fix bugs. It is then
simply assumed that the team will
spend a certain amount of time each
sprint fixing Jira- reported bugs
Put the product backlog in Jira
(i.e. ditch Excel). Treat bugs just
like any other story.
Is this really something that needs to be decided per-project basis or are there better solutions? I can think of problems with each of those approaches. Is there a hybrid coming from those approaches that works best? How do you handle this in your projects?
This is a very good question and I have some observations when it comes to different approaches to this problem.
Treating all bugs equally with backlog items might sound like a good idea in theory (work tracked in a single place) but doesn't work well in practice. Bugs are usually low-level and more numerous, so if you create an individual user story for each bug then the "real" stories will get obscured soon.
Explicit time in each sprint reserved for fixes is fine if done in a way that is visible for the product owner. Bugs should be mentioned during the daily scrum and discussion about bugs fixed should occur during the sprint review. Otherwise the product owner won't be aware of what's going on in the project.
Putting the whole backlog in bug tracking tool leads to the same set of problems as in 1. Moreover most bug trackers are not designed with Scrum in mind and using them for this purpose can be painful.
The solution we found the most satisfying was to put a single user story called "Tickets" or "Bugs" on every sprint. Then such a story can be divided either into low-level tasks describing a particular bug (if known during planning) or meta-tasks reserving a given number of hours for general bug fixing. This way the product owner has visibility into the process and the burndown chart reflects the progress.
Just remember to mercilessly close all "bugs" that are actually new features and create new backlog items for them. Also make sure to fix all the bugs reported against the current sprint before the sprint is over in order to consider the sprint as done.
Actually I think that best is answer by jpeacock from this question Do you count the hours spent on bug fixes towards the scrum?
Let me cite it:
If the bug is easy/quick to fix (one
liner, etc), then just fix it.
If the bug is not trivial, and not a
blocker, then add it to the backlog.
If the bug is a blocker then add a
task (to the current sprint) to
capture the work required to fix it,
and start working on it. This
requires that something else be moved
(from the current sprint) to the
backlog to account for the new hours
because your total hours available
hasn't changed.
The first step is to define what a bug is. I teach that a bug is only a bug if it is functionality that does not work in production as it was intended/designed. These become bug type PBIs to be prioritized against new development. Missing functionality in production is a Feature and becomes a normal product backlog item. Any defective code found during a sprint is considered incomplete work and since you don't move on to the next story until the current one is done-done; it is unnecessary to track these defects in the sprint as the team is always working on the offending code. Post-its can be super handy here for quick reminders between team-mates. Fixing broken code always takes precedent over writing new code. If the defects are due to misunderstanding the story then you need to work on your conditions of acceptance before starting the story.
Inventory is waste. Bug tracking is inventory. Bug tracking is waste.
Treating all bugs equally with backlog items might sound like a good idea in theory (work tracked in a single place) but doesn't work well in practice. Bugs are usually low-level and more numerous, so if you create an individual user story for each bug then the "real" stories will get obscured soon.
If you have that many more bugs than features then you need to work on your engineering practices. This is a smell that something else is wrong and tracking is not the answer. Dig deeper. Actually bugs are always smelly. They aren't cool and if you have lots of them you need to find the root causes(s), eliminate those, and stop focusing on tracking bugs.
Don't track defects on a list, find them and fix them -- Mary Poppendieck
Indeed, If inventory is waste, what about an inventory of defects...
That's why I always try to implement a Stop-the-Line mentality with test-driven development and continuous integration, so that we find and fix most defects instead of putting them on a rework list.
And when defects pass through, we fix them before writing new code (stories with bugs aren't done anyway). Then, we try to fix our process to make it more mistake-proof and detect defects the moment they occur.
There is no one size fits all solution and each project is different. Bugs might also be categorized from mission critical to hardly worth fixing.
Unless critical to the running of the system, I prefer bugs to become story cards. That makes the priority of feature development vs. bug fixing really explicit. In a scenario where bug fixes are considered to be "outside of the sprint" the bug fixing might move toward fixing really trivial bugs while really important business features aren't being developed.
We've gone trough a number of permutations before setting on the bug as a story approach. Try some different things and replay them at team retro meetings.
In our case (greenfield development, 2-3 devs) found bugs are written down, marked clearly as a bug and based on their severity they are assigned to next iteration or left in the backlog. In case of critical and urgent bugs they are added to the ongoing iteration.
I don't know why something as simple as fixing bugs is complicated with rules.. Scrum has very few rules, remember?
Every feature, Support, Recommendation or Defect is a Backlog issue in Scrum, there is no differentiation. So, as the Scrum guide says:
the tasks in a Sprint are never limited to what you decide during the planning meeting
the Daily Scrum helps people discuss "impediments" along their way.
Why?
So you discuss and think rationally as a team if you want the defect i.e. backlog issue to go into PBI or remain in this Sprint and deliver it...
Better question is how do I stop creating bugs in development phase?
see--> http://bit.ly/UoTa4n
If you are identifying and documenting bugs you will have to triage and fix then at some future time.
This leads to "stabilisation sprints" i.e. one whole sprint just to fix bugs. Or you can add them back to the backlog and prioritise them as part of some future sprint.
It also means that you will are providing and expect to get signed off and released software with known bugs in it (P3 & P4 aka cosmetic and minor).
This is not really agile?
I have tabled the idea in our project to introduce a short bug fix sprint every third sprint. Our current sprints are three weeks.
The idea is that it will allow all dev to focus on bug fixing together, allow focus on just new stories in regular sprints and keeps a regular focus on reducing tech debt.
Bug fixes will be grouped into relevant stories and prioritised. Emphasis is not on sizing before the sprint as devs struggle to size bug fixes without getting stuck in to understand the nature of the defect.
Has anyone tried this or have any feedback on how they think this might work?
Cheers,
Kevin.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
While the most recent Coding Horror blog entry is not the first time I had heard of the concept, as I was reading it I couldn't help but apply the it in my mind to my own project.
The code base I'm working on is an ongoing project at about the 3 year mark now, and large portions of the code in the early stages of the project were written by developers who were sub par with little oversight which lead to a lot of code duplication, poor performance, etc. In discussions with management I've tried to make the case that there are several key components that are dying to be refactored and doing so would save a lot of time and headaches in future iterations when adding new features and fixing bugs in these key areas. While they seem to trust me that refactoring these components would be nice, they don't want to give me the leeway to do it. Note that I'm not talking about a rewrite of the entire code base or anything dramatic, just a rewrite of a few core areas that would take on the order of 2-3 weeks.
The questions then, is how to you as a developer sell to your manager that these areas need addressed and make a business case to get the time to address them now, rather than having to just incrementally improve here and there?
As a manager, I'm open to code refactoring/rewriting for one of three concrete business cases: reducing technical support, adding new functionality, and improving security.
As a developer, I see two additional "close by" cases where I'll refactor/pay down debt. You might find that your manager is open to these or he may just give you "that look" that tells you he doesn't quite buy it.
First, it sometimes makes sense to refactor simply to improve your ability to add new functionality. For example, if you can see business on the horizon that will require your system to be more flexible and adaptable, then you may need to rethink some of your original architecture's commitments. This is a great time to pay down debt.
Second, when new code is being written that is related to a component that already exists then it makes sense to pay down some debt. For example, if you were adding a new class that is logically a brother class of an existing one, then refactoring out common code into a parent class makes sense. As you do this, you have a great opportunity to pay down debt as well.
The answer, as always, is "Show me the money", e.g - show a business case for your proposed solution. Traditionally this would be done by counting service tasks or help desk tickets related to the substandard code. Your specific case will be difficult because it seems you're speaking of an project not in production.
Just based on what you've written and the fact that your project is still under development, I would caution you to remember the adage "Better is the enemy of done." (I believe it was coined or at least popularized by Michael Lopp.) There might be a better time in the Project life cycle to refactor code.
If management are sympathetic, but they balk at giving you 2-3 weeks to do a complete overhaul, then a compromise would be when you're fixing bugs in those components, write some tests and do some limited refactoring, and over time improve the code.
You could just do it, or you could ask that 10% be added to estimates of bugs/features in those areas to be used for that purpose.
The main article from your link has the perfect answer already. This description of technical debt is very good:
Technical Debt is a wonderful metaphor
developed by Ward Cunningham to help
us think about this problem. In this
metaphor, doing things the quick and
dirty way sets us up with a technical
debt, which is similar to a financial
debt. Like a financial debt, the
technical debt incurs interest
payments, which come in the form of
the extra effort that we have to do in
future development because of the
quick and dirty design choice. We can
choose to continue paying the
interest, or we can pay down the
principal by refactoring the quick and
dirty design into the better design.
Although it costs to pay down the
principal, we gain by reduced interest
payments in the future.
The metaphor also explains why it may
be sensible to do the quick and dirty
approach. Just as a business incurs
some debt to take advantage of a
market opportunity developers may
incur technical debt to hit an
important deadline. The all too common
problem is that development
organizations let their debt get out
of control and spend most of their
future development effort paying
crippling interest payments.
If the project is going to go anywhere the project's manager has to care about it to begin with. If he cares about his project, that description alone should be enough to open his eyes to the idea he probably never thought of. Just help him set up a way to manage noting all the places in your codebase where things need to be improved. Maybe a group or parent ticket in your issue tracking system. That way you can have accountability and a list of what needs to be improved.
In my humble opinion, paying off on your technical debt is something you should do in small bits every time you submit code, not taking time off to do two or three weeks a year.
Continuous improvement in small chunks will work wonders in the end.
No need to ask for permission then. :-)
/Roger