3

It has been decided that the software engineering team I work in should:

  • write code for all the features our product should include by date X
  • after date X, only fix bugs

I want the best for my team and for my project, but have some doubts about whether this is the best approach.

There are plenty of bugs in our existing features, and I feel we should fix them before thinking about adding new features.

Also, I fear that having a deadline after which no new feature can be introduced will incentivize developers to write code with lots of technical debt.

Are my fears justified? If so, how can I best communicate my concerns?

closed as too broad by gnat, HorusKol, mag, mhoran_psprep, Time4Tea Oct 2 at 12:38

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Is this really a workplace issue - – Neuromancer Oct 1 at 22:47
  • @Neuromancer Exactly. They always close questions for the vaguest reasons. But this should definitely be closed. – dan-klasson Oct 2 at 3:23
  • 1
    This should belong to softwareengineering.stackexchange.com or pm.stackexchange.com, but when I try to flag it as belonging to another stackexchange site the only option available to me is meta. Why? I don't have enough reputation to chose other sites? – Davide Visentin Oct 2 at 6:57
  • 1
    I'm voting to close this question as off-topic because it belongs on another SE site (e.g. Software Engineering). – Time4Tea Oct 2 at 12:38
  • 1
    This is a recipe for catastrophe. When you are nominally at "feature complete" you will have no idea how much work is still to do to get a workable system. I have known cases where someone wrote utter nonfunctional crap and declared it a 'finished feature" and that everything that didn't work was just a "bug". – DJClayworth Oct 11 at 20:30
3

Are there drawbacks to first releasing all features, and then fixing bugs?

From a consumer perspective, nothing drives me crazy like buggy software, especially when it comes with a high price tag. A lifetime ago, I also worked in tech support for a company that took this approach and it was a nightmare. I must have said, "We're aware of the issue and our engineers are working on it" 100 times a day.

I get that management has a lot of pressure to start generating revenue as quickly as possible but they call it technical debt for a reason. In addition to making future development more costly and time consuming, nothing will make customers flock to your competitors faster than software that doesn’t work and once you lose their trust it will be very hard to earn it back.

3

It has been decided that the software engineering team I work in should:

  • write code for all the features our product should include by date X
  • after date X, only fix bugs

On my engineering team, we don't consider a feature development complete until all of the automation tests have check-ins and running on our daily builds. Your automation tests will catch the bulk of your bugs, but you should still allocate time for manual exploratory testing and stress testing your feature. We don't release the feature until both manual testing and stress testing have been completed and the critical issues addressed.

It's important to note that you'll likely never ship a feature that's 100% bug free, but at the very least you'll have high priority bugs addressed and a roadmap on when to fix the other issues.

What would trouble me if by

write code for all the features our product should include by date X

You really just mean the application code, and then you all manual test all of the components of the feature together. You really need to have unit testing on the individual pieces of the feature and integration/system tests to tie them all together. Manual testing should really be just reserved for exploratory testing or a last resort for tests that cannot be easily automated.

1

There should be some sort of QA process with your new code. Your developers should be writing tests for their code, and those tests slowly become part of a larger regression database to prevent currently working features from failing.

It is impossible to tell you if fixing current bugs or implementing new features should be the focus without more information. Sometimes, feature releases are contract-driven, while bug fixes are not. Other times, critical bugs necessitate pushing back features.

You can bring up your concern to your management or try to organize better QA practices to minimize the technical debt, but ultimately it may not be your decision.

  • " Your developers should be writing tests for their code" yeah, I wish... – EuRBamarth Oct 14 at 8:15
-1

This is actually a pretty normal way for software development to work.

Normally, compile and basic runtime bugs are found by the developer while they make the feature. The tricky bugs happen when all the features are built and have to interact with each other. Therefore it makes perfect sense to wait until the end before fixing bugs.

As for fixing old feature bugs. Sometimes these are ignored if the price to fix them is too high, or if the feature is going to be replaced or removed soon. Sometimes, the bugs take on a life of their own and become a feature of the software.

As a quick example, I once had a screen that was for a calculation, the final line, the total, was editable because it could be inserted by third party software. Funny thing is, this field wasn't locked to a number, but allowed letters by accident. Eventually a developer saw this and fixed it. A day later customers started complaining they could no longer type comments into the total field. Whoops! Nobody knew they were doing that. They weren't supposed to be doing that. But the users discovered they could, and did. Eventually it became a business requirement for the users to do this.

And sometimes the bug is really deep, and other developers have built code on top of the bug, patching it in other ways. So if you fix the original bug, you break all the code that expected that bug to be in place. This sounds silly but it actually happens a lot. It might be something like. You as a developer, discover that a core module has a function that adds 2 numbers together, but accidentally adds a 1 to the end all the time. 1 + 1 = 21, 6+6=121. So you contact the developer that wrote the module and ask them to fix it. It goes to the backlog because they are busy working on a feature, no time to fix bugs. But your on a deadline. So you just write your code to chop off the last character of whatever the function returns. Job done. A month later, that core developer fixes the problem. Now your code is broken.

This is a very simplistic example but I hope it gives the right idea.

So the drawbacks of this system are that bugs will often be deemed too expensive to fix. But the positive side is development speed is drastically increased as developers aren't trying to debug someone's code all the time while working on their own.

  • 2
    Code built on faulty code is the real issue here. You eventually have a stack of code relying on a bug and just a ton of work around patches to ensure your new feature works that the code base becomes unmanageable. And because each person releasing a feature tacks on their own "fix" no single person knows exactly what it does. – Shadowzee Oct 1 at 23:49
  • @Shadowzee That's how software development works in big companies. It's terrible I know, but it's all part of working in the real world. Do you think Microsoft developers like pushing bad code to millions of people? Do you think they wanted onedrive to delete peoples profiles? Of course not. But that's how modern software development is done now. Quick and dirty and hope it works. – Trevor Oct 2 at 12:37
  • Not all Big Companies. Sure Microsoft has a ton of legacy code from decades back but new software is often very Object Oriented, focused around Micro Services or exposed through APIs. This way, the reliance on extremely long chains of spaghetti coded horrors is broken up which allows for much easier debugging and bug fixing. That is modern software development, and it is completely different from supporting legacy software features because there is a wealth of software designed for an older system you created. – Shadowzee Oct 3 at 0:10

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