23

The code is a complete mess of a combination of classic ASP/ASP.NET. The scrum consist of us patching up the big mess or making additions to it. We are all too busy doing that to start a rewrite so I am wondering..

Where is the part in Scrum where the developers can have the power to say that enough is enough and demand that they are given time to start the big rewrite? We seem in an endless loop of just patching old code with 'Stories'.

So things are being run by the non-technical people who seem to have no desire to push for a rewrite because they don't understand how bad the codebase has gotten..

So who is in charge of making this big rewrite change happen? The developers? The Scrum Master?

The current strategy is just to find time and do it ourselves without the higher-ups involved since they are mostly to blame for the current mess we are in.. <- insert rant about non-technical people telling technical people what to do here ->.

Improve this question
20
  • 20
    Sham agile raises its ugly head again... Many companies say they are "agile" and use "scrum", when in fact they do neither.
    – Oded
    Apr 12, 2012 at 10:16
  • 4
    You are not doing Scrum
    – user2567
    Apr 12, 2012 at 10:27
  • 20
    consider printing a large poster of this and placing it on the wall right where your non-technical people can clearly see it: Manifesto for Half-Arsed Agile Software Development ...while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right
    – gnat
    Apr 12, 2012 at 11:19
  • 12
    obligatory link to Joel's blog : joelonsoftware.com/articles/fog0000000069.html
    – marco-fiset
    Apr 12, 2012 at 15:48
  • 8
    "<-insert rant about non-tech people telling tech people what to do here->", management should 100% percent be telling tech people what to do, that is why they are management and responsible for the business, that is what they do best. What they 100% should not be doing is telling them how to do it, tech people should decide on how to technically achieve what they have been asked to do. Anything else is complete naïveté!
    – user7519
    Apr 12, 2012 at 20:01

12 Answers 12

Reset to default
7

I'm not sure why this is so hard for people. His business case is right here:

We seem in an endless loop of just patching old code with 'Stories'.

Developer time is money. Lots of money. I left a company that planned on revamping their UI over a year ago and hoped that adopting scrum would help them stop spinning their wheels. What happened? Same ol' same ol'. They continued to bolt new features on and "technical debt" had no business case even though half the code we wrote became meaningless with every iteration due to the underlying codebase being a complete outdated mess. Not one thing has changed on their front end since I left, and I was brought on for the very purpose of completely revamping it. In the two months I was there I didn't actually touch a lick of CSS or JavaScript. I was just messing with HTML and some ancient Java templating system from the late 1990s.

My answer? Do what you can, but if the other developers have already given up and are working late to meet sprint goals rather than assert more practical deadlines and insisting that tech debt is in fact a blocking issue, assume the worst and start looking for a new job now. Your developers are either unable or not allowed to communicate their concerns or business is too !@#$ing shortsighted to understand how much money they're pissing away.

Ignoring these problems ALWAYS costs more in the long run. And not a little bit more, but a LOT more. Not only is it a sucking chest wound where development time is concerned, but it's also inevitably going to reduce your talent levels as developers who know better and have other options will avoid your company like the plague. My current boss is a developer AND the owner of the company. There's stuff we won't rewrite in favor of focusing on other priorities, but when something truly needs a refactor due to being a consistent timesink, it gets a proper refactor. And the results are obvious. Modifying and adding new stuff becomes easier and faster by multiple factors. What once may have taken hours can take minutes with proper architecture. Business doesn't like to hear it, but it's worth putting things on hold for that.

Scrum is a failure in environments where developers don't hold a lot of sway, IMO, because it's too easy for the business types to want to ignore maintenance and updates in favor of bullet points they can put on their "successful initiatives" lists when evaluation time comes around. They will always favor their hides and potential for promotion in favor of the long-term, even when it consistently bites them in the ass to ignore these issues too.

Scrum is also a profit-motivated industry and then some. Companies pay a lot of money for scrum training. People looking to adopt should cast a wary eye towards who is being marketed to and how realistic it's really going to be within their given culture.

Regardless, if you actually give a damn about development, a crappy codebase, management with wax in its ears and developers without spines is a recipe for misery and an environment that will do very little to enhance your skillset in any useful regard. Don't hesitate to start putting steps in motion to GTFO before you've actually discovered whether your efforts to fix the problem are actually paying off.

Improve this answer
8
  • As regards refactoring, I find it odd that people can't 'internalise' that refactoring is a constant part of all development, not something you have a bash at when the problem is so bad there's not much you can do.
    – nicodemus13
    Apr 12, 2012 at 17:51
  • 1
    Or you don't have unit tests. :) One of the main benefits of unit-testing is that it allows you to refactor with confidence. The biggest problem with good practice is the same as everything- it requires discipline and generally people prefer to be lazy.
    – nicodemus13
    Apr 12, 2012 at 17:59
  • 2
    That or they're yet another gift from the extreme coding crowd that can just as easily be turned into a tool that enables bad behavior in the wrong hands. Automated tests are useful at key points but I prefer sound architecture and writing to an interface rather than a test.
    – Erik Reppen
    Apr 12, 2012 at 18:10
  • 1
    I would say that's the same for anything, personally I write the tests to help define the interface.
    – nicodemus13
    Apr 12, 2012 at 21:06
  • 1
    Then comes the pain of all the kludges to be put back in as there are those little exceptions that may not easily be caught by the initial analysis.
    – JB King
    Apr 13, 2012 at 21:55
32

If you would really be doing Scrum, which I doubt, the Product Owner would be responsible for deciding about a rewrite. Most of the times a rewrite is not a good idea, btw, because it produces no new functionality, only introduces new bugs.

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

To expand on "rewrite is not a good idea":

It is almost always better to try a gradual improvement. Like Jarrod Robertson wrote in a comment, find a module that needs improvement become the expert for that module and write a story for the next sprint for improving that particular module. Explain to the product owner why that module needs work.

Improve this answer
15
  • 8
    If you have as much experience and wisdom as you claim, step up and be the guy that figures out that failing module, become the expert on it and fix it, and then put together a business case to re-write it, because then you will be the expert on that module.
    – user7519
    Apr 12, 2012 at 15:48
  • 3
    Some messes need to be cleaned up. Quoting Joel articles and asserting that rewrites rarely pan out without any statistics which would be dubious anyway (because who brags about successful rewrites?) does not change that.
    – Erik Reppen
    Apr 12, 2012 at 17:28
  • 3
    @ErikReppen So when your living room is messy you tear down the house and build a new one?
    – EricSchaefer
    Apr 12, 2012 at 18:29
  • 4
    If you read his comments he's not talking about the living room. It's probably difficult to tell where one room begins and another ends. And the whole house is on fire.
    – Erik Reppen
    Apr 12, 2012 at 18:36
  • 5
    Whoa there, cowboy. Before we just make a blanket statement about "rewrite is not a good idea", I think we need to qualify that with the truth that moving to new technologies and adapting to the times is essential for the IT-survival of your business. If you don't adopt newer (hopefully better) technologies and the advantages they give, your competitors will. This is true of tech in general. The Model-T was a perfectly good vehicle, but thanks to competition and the adoption of new technology, cars have been "re-written" many times over into the much better vehicles we drive today.
    – blesh
    Apr 12, 2012 at 21:04
18

I'm going to be really blunt...

  • Are you in charge of the developers in this job?
  • Are you the project leader?
  • How much "stake" do the developers hold in the project?
  • What is your business justification for a rewrite?
  • What is it about the code base that makes it entirely useless and unrecoverable?

You've stated that you have just started a job, and yet you already appear to be a master of the situation there. Perhaps I have misunderstood the intent of your question, but I get the impression that you've entered a job where you see a number of problems, and you have jumped to the easiest conclusion in which the code is broken and the only way forward is a rewrite, but have you really considered the cost to your employer to do so?

With any existing code base - no matter how poor a state it is in - the owner will usually have a sizable investment in the product(s) the code represents. There are both direct and indirect costs associated with the code base, and a rewrite is often the very last thing you want to do as a software developer, as you risk devaluing your code assets, and thus getting a lower return on all of your prior efforts.

Take the Window's operating system as an example. With each new version created, there has been a big chunk of code carried forward from the previous version. Sometimes, entire libraries and APIs are dragged forward across several generations of OS. Why? Because the developers know that these elements work, have been tested, have been patched and fixed to prevent security and memory problems, and because they have cost a hell of a lot of money to get into that state. Nobody wants to throw away working code when it is making them money, even if the maintenance costs are relatively high, the cost to start from scratch will always be higher still, and in a company like Microsoft's case, they have billions in the bank which allow them to start from the beginning if they want to, but they don't because they want to maximize their return from their investment. Your employer is no different to Microsoft, except for the bit about having billions in cash to throw at a project.

So the code is a mess, and it sounds like there are communication and boundary issues between the various areas of the company. What can you or your colleagues do about this?

One option is to simply continue on as the team has been, and hope for a miracle in the future. Probably not a good idea, and likely to only increase your frustration and stress.

A better option is to simply knuckle down and do your jobs, but as a part of this look for opportunities to add tests to support those areas of code that appear to be the most fragile, then refactor them until they become more stable. You'll have an easier time making a compelling argument to improve the company's investment instead of arguing to simply throw it all away.

An even better option is to be organised as a team, and to ensure you get someone on side with enough seniority that they can make a good case to allow the team more flexibility to schedule time to improve the code base. I don't care how busy a company is, or how rigid the schedule appears to be, there are always the occasional "lulls" in activity that can be used to squeeze in an improvement or two. It's even better however if the improvements can be made while completing other tasks. If it were me, I'd be cozying up to a manager and introducing them to concepts in some of the canonical books that software developers read. Clean Code is probably the one your team needs the most. Plant a few seeds about how to improve the code, and provide a few examples of what you mean. A good manager will see the value of adding incremental improvements to code, especially if you are able to describe the concept of Technical Debt. Help your team leader or manager to make a good business case for improving code, and they'll have a better motivation to act on it.

It's also not enough to say "the code is untidy". You need to encourage your colleagues to practice coding clean all of the time, and to use clean coding technique to encourage a little tidying up as you go. I have a little poster that I print out and hang from my office wall every time I take on a new job. It says "Always strive to leave the code a little more beautiful than you found it". Right next to it I add another which says "Lilies don't need to be gilded". They both serve to remind me that I should always try to improve what I find, but avoid simply gold-plating one problem with another. Massive rewrites are often the worst sort of "gold-plating", because they are often done for the wrong reasons. Sure an entirely new product version might be justifiable at some point, but rarely simply because the code base is a mess.

Improve this answer
12
  • No. I am not in charge. I am a dev that has coded 12 years professionally and 7 years .NET. I have been around on many contracts and after awhile you quickly can get a feel for the quality of code . How much 'Stake'? I am not sure what you mean by that. We can keep plugging away fixing the old CLASSIC ASP that is now extremely fragile and take 10x longer to do than if these changes were part of a good modern arcitecture. The business justification is that the site is now crashing in production due to a module that no one seems to understand because of the high turnover
    – punkouter
    Apr 12, 2012 at 13:19
  • I don't think you understand just how bad this code base is. On top of that, this is not rocket scienece. This is CRUD 101. This is displaying a form , letting a user fill it out, validate and then create some reports and PDFs from the data. That is basically it.. But over 10 years the code has been fragmented into so many peices its awful. Ive been part of about 20 projects the past 12 years and this has got to be the worst collection of code I have seen that is actually used in production... I wish I can show you all
    – punkouter
    Apr 12, 2012 at 13:22
  • What I am doing for starters is finding the people who are on the team who have some passion for coding and are interested in being part of finally getting this right. It is not easy to find those people because of... brucefwebster.com/2008/04/11/…
    – punkouter
    Apr 12, 2012 at 13:24
  • 16
    @punkouter: I don't think you understand the point being made here; The codebase being "bad" is not a business case for a rewrite. Having passion for coding and wanting to get things right is not a business case for a rewrite. Costly production bugs and outages, and taking months to implement trivial but important new features - THOSE provide a business case for a rewrite.
    – Michael Borgwardt
    Apr 12, 2012 at 13:47
  • 1
    @punkouter Your link to a description of the "Dead Sea" phenomenon is also particularly apt. It is of no value to the business to lose knowledge through attrition, and of great value to reclaim what it can. An investment of your time to avoid a potentially expensive and unnecessary rewrite has greater business value than losing knowledge and expertise. Encouraging better hiring practices, and rising to the challenge of chipping away at the problem and improving the system is an opportunity for you to earn a little kudos and become a valued asset to your employer.
    – S.Robins
    Apr 12, 2012 at 13:59
13

Here is the official definition of the Scrum Development Team from the official Scrum Guide. I put emphasis on the parts that concerns you directly:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics:

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;

  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and,

  • Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.

The Development Team is therefore responsible of its own mess and should address it itself, without having to ask anyone outside the team.

Include a technical debt fixing time in each of your future estimation, and ensure that the quality of the software you deliver is top notch.

If you really have to do a complete rewrite, you must address the problem at the Scrum Restrospective. Product Owner may eventually cancel the project and start a new one. Product Owner is also the only one able to cancel a sprint.

Improve this answer
8
  • 8
    The team is responsible for their own mess, but they don't get to choose the priority of technical debt versus new features. It is the product owner who decides that. It's just that, once the PO has decided on the priority of the backlog, the team can decide how to deliver it. They can say "we can't deliver feature X without first refactoring Y" but they can't say "no, sorry, we won't add any new features until we rewrite it from scratch".
    – Bryan Oakley
    Apr 12, 2012 at 10:48
  • 6
    @BryanOakley: Rewriting from scratch is not what I suggest. I suggest to reduce the technical debt progressively as the development team work on the concerned areas. And I also suggest that they estimate accordingly.
    – user2567
    Apr 12, 2012 at 10:59
  • 1
    That sousd good but what if we need new servers, new databases, new software in order for us devs to have all the tools we need to do the rewrite ? ANd how does the rewrite begin when the only 'Stories' are about fixing current problems and never about the concept of allowing a rewrite ?
    – punkouter
    Apr 12, 2012 at 12:58
  • 1
    @punkouter: if you have to rewrite, address the problem at the scrum retrospective. Then the Product Owner will take the responsability to cancel the current project and start a new one.
    – user2567
    Apr 12, 2012 at 13:24
  • 5
    Don't assume that the decision to rewrite is the 'right' one just because it's the one that appeals to the devs most. Sometimes there is a good business reason to deliver features now, even though it's going to increase technical debt.
    – DJClayworth
    Apr 12, 2012 at 16:38
8

As you describe this, I have to say I don't see anything that has anything to do with SCRUM, or your product development team being a problem currently.

This is Normal

What you describe is the normal entropy of a code base. In your case, the team probably started off farther off from ideal, but still every code base eventually becomes a Big Ball of Mud.

In a completely perfect greenfield scenario, all you can possibly do is start farther from absolute entropy and move towards it slower.

I agree with others, the code base mess is because of developers. I am sure it predates the adoption of SCRUM by many years.

This isn't a technical or developer decision to re-write, it is a business decision.

You aren't privy to why the product owners don't want a re-write. You as a developer think it is needed, but is there really any business case for it?

If there is a true business case, not just a hand waving; "the code is a legacy mess I want to start greenfield because that is what I want", then management would entertain the expense of a re-write, given a consideration of a return on that investment.

You haven't given one solid business case for a re-write, just a rant about your opinion on how everyone else caused this mess and you don't want to deal with it.

Proof - Profit drives business decisions to toss out working software, not some OCD need for a clean code base

If you can really show proof, not just theory but hard proof that spending X dollars on a greenfield re-write will be guaranteed to MAKE X * N dollars for the business in Y time frame ( where N is high and Y is short ), you might get some traction from management. This is a highly unlikely case that you can present and prove.

Otherwise you just need to deal with it, this is reality. Contrary to your adamant assertions that there is absolutely no way forward without this grand immaculate re-write, I would bet money that 5+ years from now code base you are complaining about will still be working and running somewhere providing someone functionality and value long after you have left the company.

Improve this answer
10
  • 1
    that doesn't mean it isn't the responsibility for the developers to use some version control system internally regardless, I would say it is still the developers responsibility to take care of themselves and their best interests regardless. In your straw man, those 200 devs didn't do what they needed to do, management didn't put a gun to their head and forbid them to set up version control system themselves.
    – user7519
    Apr 12, 2012 at 16:14
  • 3
    Messy Code bases are never a direct result of management since management is never directly responsible for writing code. Its that simple. Manangement is responsible for having and fostering a less than ideal working environment for the developers, but the responsibility to work through problems such as a lack of version control always falls on those doing the actual work.
    – Peter Lange
    Apr 12, 2012 at 16:57
  • 1
    Outsourced devs is a management problem. People on the inside knew better. Management liked to pretend they were saving buttloads of money by hiring 200 devs when they in fact probably could have done great with 20 competent ones. Much like a lot of Scrum implementations I've seen, the adopted strategy was the product of incompetence and nothing the devs that were actually company employees had any control over.
    – Erik Reppen
    Apr 12, 2012 at 16:59
  • 2
    @Erik, not saying managers dont have to take responsibility for a bad code base (or any other bad decisions made in their department) and that managers arent directly responsible for providing the environment in which the developer work, such as the scenario you described. But the only person who can be directly responsible for the code base is the person writing the code itself.
    – Peter Lange
    Apr 12, 2012 at 17:17
  • 3
    I would also like to add that it is stupid to not make your devs privy to business goals. I've never understood why people are so intent on hiding this stuff from the people actually determining the behavior of their product. Knowing a company's long-term goals can in fact inform how you architect an app. Also, devs, good ones at least, solve problems. Constantly, they solve problems. Some of us anticipate and solve them ahead of time in our heads or at least leave the right doors open in our code.
    – Erik Reppen
    Apr 12, 2012 at 18:48
7

I'm usually skeptical when people push for "big rewrites". There are some cases where it definitely makes sense but most of the time, that legacy code has value (in that it's already in production and being used for the purposes that inspired its creation). Performing a big rewrite is in many cases the opposite of agile. How long would it take to bring the new version of the application to a point where it can viably replace the existing application.

The approach I'd prefer is what Martin Fowler calls the strangling vine. Implement new functionality (including changes to existing functionality) using the new approach but use the existing application as a trellis which the new functionality can grow upon. This gives you the best of both worlds, you don't have to stop everything while the big rewrite is being brought up to snuff, but you get the benefit of writing new code that takes advantage of updated frameworks. It's definitely a more difficult approach than starting clean and might not be as sexy, but it provides more value to the business than dumping everything that's there because it's outdated.

Improve this answer
4
  • That can be difficult if the existing base is enough of a mess. He's talking about multiple legacy asp.net systems by completely different authors tightly coupled together for the same damn site. Web forms alone is a monster and I'm sure that's in the mix.
    – Erik Reppen
    Apr 12, 2012 at 18:02
  • Oh I never said it would be the easiest route...but it's more palatable to stakeholders. Also, going through it once, hopefully you'll make sure that when today's latest and greatest becomes tomorrow's outdated, it's easier to phase it out.
    – Michael Brown
    Apr 13, 2012 at 12:36
  • I agree. But like Ive said (and not sure everyone heres) .What exissts now is a collection of about 9 seperate web applications half being Classic ASP and the other half being differnt forms of ASP.NEt. All using totally differnt ways to handle data access etc.. So the only way to do what is talked about is to fake the UI to look like the new code is part of the old code.. so yeah maybe.. but then theres a the database.. One table has 400 fields!
    – punkouter
    Apr 13, 2012 at 21:29
  • I'm curious. What does that table represent? That's the worst thing I've heard of since I saw i++; doSomething(i); repeated over a dozen times in some code that spilled out of a busted JSP tag.
    – Erik Reppen
    Apr 19, 2012 at 17:17
5

Where I am and how we work this is what we would do: Write a new story and hand it to the product owner, who will then decide how to prioritise it. An example would be: "As a Developer of Product X, I would like to re-write the code in this area so that future development is more efficient" Acceptance criteria would then need to be along the lines of: Re writing / refactoring x so that it is better in this way.

I don't know about the situation where you are but here if we wanted to re-start from scratch it would be a case of sitting down with the product owner and persuading them why and then writing a pile of stories to re-create existing functionality.

The other things we've done to try and deal with bad and / or legacy code have been to include tasks for reworking when tasking out the user stories.

Improve this answer
11
  • So the devs can write 'stories' and submit them ? The problem is explaining the reasons for re writing is too technical for them to handle... All I can say is .. 'The current code is hard to manage and breaks'..
    – punkouter
    Apr 12, 2012 at 13:14
  • 6
    @punkouter: if the reasons for wanting to rewrite are purely technical (i.e. not costing the business money) then you HAVE NO sufficient reason for a rewrite.
    – Michael Borgwardt
    Apr 12, 2012 at 13:49
  • @MichaelBorgwardt: Are you saying that any technical reasons are never sufficient for rewriting something? That's a fundamentally broken approach, if I understand you correctly. One thing that continually gets on my nerves is the normal master/slave approach that the 'business' determines everything that 'IT', or any department does. That is only true to a certain extent. IT has its own requirements that are internal and are not decided by the business- this is one thing that is usually missing and leads to non-engineered, not fit-for-purpose software.
    – nicodemus13
    Apr 12, 2012 at 17:44
  • 1
    @user12355 As I have seen, Michaels point is that if it isn't losing them money, it won't make them money, then there isn't ever a case. If they aren't losing money a rewrite costs them money. Money that can't be recovered. A developer could make the case of "this code sucks" but unless they can prove a financial benefit to their employer they will never get the green light to rewrite unless they do it on their own.
    – Rig
    Apr 12, 2012 at 18:16
  • 1
    @user12355: Technical reasons are definitely sufficient for a user story. They're not necessarily sufficient to get that story promoted to the top of the list and placed into a sprint.
    – Adam V
    Apr 12, 2012 at 20:12
4

Deciding on big rewrites is a business decision. You can try to influence business decisions by selling in your point of view to the people responsible for the business part of things.

However; the change in code quality from one iteration to the next is a developer decision. If you allow the code quality to decline, you are adding technical debt in order to fulfill the product owner's expectations now. What you can do is to start taking responsibility for the code you write and make sure it improves the code base, not the other way around. Now this means you will lose velocity, since you are continuously decreasing the amount of technical debt, and your product owner will surely be dissapointed. You can try to explain that in your eagerness to please, you've let the code quality degrade and you're now taking steps to correct this issue.

Now, I realize that it's a terrifying step to take, and it might feel tempting to delay it just one more sprint so you can get out feature X before an important deadline. Unfortunately, it will just get more difficult the longer you wait.

By the way, this is not strictly a Scrum issue, nor am I suggesting a solution that is specific to Scrum. This is about developers taking ownership of the code.

Improve this answer
2
  • 1
    Right and when you have a history of 10 years of constant turnover and one-offs by devs who clearly could not code well or understand modern arcitecture then.. you have what I have now... I am alarmed more than anyone else since I am new to the job and not use to seeing such a low quality level of code.. I want the rewrite not just for my selfish desire of enjoying writing new good code.. but for the sake of everyone else as well .. even if they do not understand the situation as I do.
    – punkouter
    Apr 12, 2012 at 13:30
  • 1
    I can only reiterate what's already been said; Formally, you can't decide that now is the time for the big rewrite. I guess you could try to show stakeholders how much effort it takes to incrementally turn your codebase into a slightly less painful state, and compare it to the effort it takes to do a complete rewrite.
    – Buhb
    Apr 12, 2012 at 13:51
3

The developers are responsible for alerting the world on the code base's current state. This can happen during a daily scrum, a retrospective or just informally. It may seem obvious but if you don't express clearly what a mess it is and how much time you waste because of it, no one will ever notice. The Scrum Master will typically be responsible for passing the information on to the PO and the people in charge of the project and persuading them something needs to be done, and then facilitating the implementation of a solution by the team.

As a side note, a big bang rewrite is IMO not necessarily the right answer to this kind of problem. However fed up the devs are with the current code base, taking small measurable steps towards a cleaner architecture is often a better idea since you can see the progress, justify your work by regularly showing the PO the accomplishments and continue the flow of implementing new user stories in parallel as opposed to getting lost in an endless, resource-monopolizing makeover.

Improve this answer
5
  • As I mentioned.. There is no way forward with a collection of 6 Classic ASP sites + 4 .net 1.1 sites that are all combined into one site. All coded by different people in different ways.
    – punkouter
    Apr 12, 2012 at 13:27
  • I am pretty sure that code base will move forward, for years to come, to paraphrase Dr. Ian Malcom from Jurrasic Park "I'm, I'm simply saying that management, uh... finds a way".
    – user7519
    Apr 12, 2012 at 17:10
  • It might be around in years to come but varying flavors of legacy .net sites tightly coupled together is not likely to move very far in those years.
    – Erik Reppen
    Apr 12, 2012 at 17:54
  • Sure, but if all those .net sites continue to function, and their functioning continues to generate revenue either directly or indirectly for the company, why is forward momentum so important? When the revenue is directly impacted by the quality of the codebase, you can believe that the managers will waste no time in redesigning it as they all have mortgages to pay just like the developers do.
    – Peter Lange
    Apr 12, 2012 at 18:47
  • Ceaseless forward momentum is generally the root of the problem in the first place in my experience. The pain starts when turnaround expectations don't diminish while they still turn a deaf ear to the problems in the architecture and think Scrum is going to magically develop new sets of complete features every two weeks without further exacerbating the problem. I'm not saying we shouldn't be wary of the urge to rip stuff out if we can't come up with alternatives that solve the time sinks we're encountering, but I've seen at least two very good cases for major overhauls in my career.
    – Erik Reppen
    Apr 12, 2012 at 20:42
2

You asked:

Where is the part in Scrum where the developers can have the power to say that enough is enough and demand that they are given time to start the big rewrite? We seem in an endless loop of just patching old code with 'Stories'. So things are being run by the non-technical people who seem to have no desire to push for a rewrite because they don't understand how bad the code base has gotten..

As someone who is both a manager and a developer, the simplest answer to your question is there is no part in Scrum, or any other methodology, or in any business scenario, where the developer have the power to say enough is enough and demand a re-write. Many people here have made good, valid, arguments to explain why re-writes are frequently bad ideas, and to explain how change can and should be brought about in an incremental, agile fashion. And I agree with them all.

But the bottom line is even simpler. You don't get to make that decision, EVER. You are the employee, and the only decision you really get to make is "will I continue to work for these asshats or find a new job that fears my mad skillz." Your new job won't allow you to make that decision either, but at least you will feel like you are in control of your fate as you hop from job to job.

Improve this answer
6
  • 1
    If I'm reading between the lines here correctly, it sounds like you're a bit bitter about your inability to hold on to new-hires. If I'm not wrong, have you considered that the new-hires whose skills are in fact in enough demand for them to walk when they don't like working at your company are the only non-constants in the equation?
    – Erik Reppen
    Apr 12, 2012 at 17:48
  • 1
    Not even close. Actually the employees in my department have been with me for a few years now. I have virtually no turn over. The point I am trying to make is that ultimately, in any company, in any industry, what work the employee performs is completely up to the person signing the paycheck and not the employee. The only decision the employee has to make, myself included when my boss makes a request, is to persist or not persist with the employee relationship. The original poster asked when does he, as an employee, get to dictate development. The answer is never.
    – Peter Lange
    Apr 12, 2012 at 18:20
  • Then what was with the "fear my mad skilz" characterization? This guy is an experienced dev. And I can tell you from my experience with similar situations that the problem he's talking about is not just a matter of wanting things his way but actually an on-going disaster that is both making everybody miserable and costing his employer a lot more in wasted dev time and talent retention than they probably realize.
    – Erik Reppen
    Apr 12, 2012 at 18:34
  • 1
    Because I was illustrating the fallacy of the basic argument, which was rooted in ego (in a psychological sense.) Its not a question of how skilled he is. Its not a question of how messed up the code is. Its not a question of what the development methodology can do for him. It is a question about power. The power to make decisions in an employee relationship resides with the employer. The only deciding power an employee has is to cancel the relationship when it becomes too much to bear.
    – Peter Lange
    Apr 12, 2012 at 18:44
  • 1
    I agree, scrum is lousy for dealing with tech debt. But I disagree about the basis of the original question. He was in fact asking a employer / employee relationship question, but just mentioned scrum in the question. Its like if I asked, "As a Christian, whats the best way to make an Enchillada?". Its not really a theological question; its a question about cooking even if I made the mistake of thinking my religious preferences were relevant.
    – Peter Lange
    Apr 12, 2012 at 19:03
1

I feel your pain, but am not sure what it has to do with Scrum. The decision whether to re-write code does not depend on the development process.

Improve this answer
1
  • A development process that promises things will get completed every two weeks can do a lot to stand in the way of needed large-scale refactoring that's been ignored for years. The first thing I noticed in scrum training is the way they sort of glaze over the topic of tech debt. It's not exciting to declare that your app is now leaner and meaner and you can do things faster. Business types want visible value adds they can show to friends and investors.
    – Erik Reppen
    Apr 12, 2012 at 18:22
1

Wait....what?

You're patching? You should be refactoring. Stick to agile values. Use TDD and appropriate practices and the situation will eventually become better.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.