6

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?

closed as too broad by user53019, gnat, Bart van Ingen Schenau, gbjbaanb, durron597 Sep 22 '15 at 1:47

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.

4

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.

  • 2
    bullet 3a - Some companies just accumulate the debt without ever paying it down. – Dan Pichelman Sep 21 '15 at 15:40
  • Thanks for your answer. Maybe 'compromise' is the wrong word. I understand products won't be perfect, I'd just like to be confident behind my code at launch time. And it seems like that is out of my control many times, which is frustrating. How did engineers design and build the Golden Gate Bridge with confidence that on opening day, cars wouldn't go plummeting into the bay? – hgwhittle Sep 21 '15 at 15:44
  • @DanPichelman - I would argue that those companies' end result is not a great product. – Telastyn Sep 21 '15 at 15:45
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

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