How to balance quality vs. speed during the development process [closed]

Question

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

I've been in the professional software development world for over 5 years now. An intense frustration that I've had over the years is when a software product that I'm working on turns out unstable, fragile, and compromised. Of course this always seems to happen when I'm rushing to develop several new features and meet a very aggressive, seemingly arbitrary deadline.

The new features require careful design, solid development, and thorough testing. However the importance of meeting the deadline compromises every one of these processes, resulting in an extremely fragile application.

I'm confident in my skills and experience as a developer, and I know that I can produce a great software product given the right environment. But it seems like when these types of projects come up, it's impossible for me to do my job well, and I can't stand behind my work.

How do great software companies handle this problem so that the end result is a great product?

Answer 1

How do great software companies handle this problem so that the end result is a great product?

Different companies handle it differently.

• The most obvious candidate is that they don't have very aggressive or arbitrary deadlines.
• Some companies don't give a crap about producing great software products, since consumers are fine with shoddy ones and/or great ones cost too much.
• And some companies require an aggressive deadline because time to market is important for them. They go back later and pay down the technical debt.

But one thing to note is that there will always be compromise. You will rarely ever have the time you need to get things perfect. You will almost always include features that seem pointless.

These things shouldn't make your software unstable or fragile. These things shouldn't involve a death march to the deadline. That isn't compromise.

Compromise is coming to some middle ground where both parties' needs are addressed.

Answer 2

Testing.

If you test fully each bit of code you produce, then you can have confidence in it.

If the test fails, you can say definitively that there is a fault and the business can make a decision to live with that fault, but you will have called it out.

If you want time to write more tests but the business won't let you have that time you can legitimately say you are not confident because it is not tested. (ensure you can list the tests you would like to run before you are confident!)

But at some point you have to had over some completed work which you are happy to say meets the requirements.

Of course hand in hand with this comes requirements. I think this tends to happen because devs are told to produce stuff that meets high requirements 'we need to support a billion users!' when really the actual requirements are much lower. 'why is it taking so long?! I just need something to demo at the show next week for 5 users!' then it goes live and you can be caught out, 'we said a billion users!! and its fallen over with only 1,000,000!'

One of the things a good dev will be able to do is walk the fine line between asking for requirements the business just cant tell you and looking belligerent and just knocking something up which demos ok but wont be a good product when live