Is it normal for a software developer to have lots of issues after product went live? [closed]

Question

In recent months, our product (which went live probably 9 months ago) experience an increase in the number of users using it. We faced lots of queries, problems, and complaints from users. Sadly, it seems that a lot of the issues seem to be coming from a module that I have been working on.

At times, I wonder if I am incompetent, or is this pretty normal in software development, that bugs are found especially during the initial stages of a software development livecycle after it goes live? I wonder why some issues we faced now are not foreseen by me or the team during development phase.

I have been working as a software developer for close to 2 years now.

Hope to get your opinions, feedback, advices!

Thanks!

Answer 1

I wonder why some issues we faced now are not foreseen by me or the team during development phase.

Probably because you have no psychics on your team.

Seriously, this happens all the time, so don't worry! The analysts and experts and developers can't anticipate everything that a user might want to do with a product. That's why there's a feedback cycle where users say "I wish your product had Feature X and could perform Action A" and the analysts and business experts and developers get together and plan the next release, which will have Feature X. And repeat...

a lot of the issues seem to be coming from a module that I have been working on...is this pretty normal in software development, that bugs are found especially during the initial stages of a software development livecycle after it goes live?

Hard to say, it depends on the product, and on the testing procedures that are used before it goes live. A more rigorous and thorough QA process will reduce issues after go-live, but is more expensive and if you need to get to market by a hard deadline, you might not have time for the rigour you want.

And maybe so many issues are coming out after going live because the analysts who wrote the requirements didn't understand what the users wanted, or maybe the users don't quite understand what the program is supposed to do.

As for feeling incompetent because your module is responsible for many bugs... Again, I really can't say for sure without knowing more. Maybe your module was the one with the most complex business logic. Maybe it had the least amount of testing. Maybe the requirements you were given were not well written and poorly understood (by you or the person who wrote them). Don't take it personally, try to view it as as learning experience of how to improve your skills for the next release.

Answer 2

Yes, your number of issues will rise proportionally to the number of people using it. More people means more eyes on the product, and more variety to the people involved. More eyes means that someone is bound to see an issue if it exists. More variety means that more of your corner cases and/or code paths will be exercised. For certain apps, more people means more stress if they share resources (like a database, etc).

And people tend to naturally complain, some more than others. More people means more of the squeaky wheels.

That said, if your product is getting more complaints that a similar product then someone failed somewhere. Maybe it was design, maybe it was planning, maybe it was implementation, maybe it was testing. Maybe your customers are more demanding than others'... Only a few of those are the programmer's fault.

If on the other hand your module is getting more complaints than other modules, then yeah; that lowers the number of potential causes. It might be that your module is used a lot more, or was more complex, or is more visible. Or perhaps the QA assigned were less then stellar. ...or perhaps you didn't do a good job.

It is, in the end, only one sample. It might be an abberation, or it might be the start of a trend. You should assume that it is your fault. The only way you're going to get better is by looking at what went well (and do more of that) and what went poorly (and do that better). Blaming others, or accepting it as 'simply the way it is' prevents this vital retrospective part of personal growth.

Answer 3

Bugs after deployment to production are a fact of life. No matter how hard the piece of software is tested something you never even dreamed about will come along and cause something to fail. If you don't have a (good) QA team testing your code, and automated testing setup, the amount of bugs after deployment could be rather large. Developers by and large tend to fall into the habit of testing the so-called "Happy Path" in their code while writing it. They forget to go back through the other paths.

What would raise red flags is if the bugs people are finding bugs in core business rules. For example, if you created a web form that allowed people to enter their email address but no syntax validation was being performed on it. Or, all users must have an email address, but you don't require it in the form. Another red flag would be if the bugs caused security issues, such as direct injection of SQL into your code.

But if the bugs only happened if you had to follow some insane set of steps such as, the user put their cursor on the test box, held down the space key for 10 seconds, hit tab six times and then clicked a drop down list and exception would occur then I wouldn't stress about it too much.

The fact of the matter is, the module went live and there are bugs in it, you can't change that. After getting them fixed, I would focus on preventing these bugs from ever happening again. If you or your team doesn't have automated testing (both unit and integrated) then I would take a real hard look at it. Because automated testing does what developers tend to forget to do, regression test, as well as test new features. I've mentioned this book before in previous posts, but I will mention it again, the book The Art Of Unit Testing will give you a good foundation. Automated testing will not be a cure-all for this problem. But well written tests should reduce the number of found bugs.

Finally, hopefully you have a QA team testing your code, if you do then I would have a postmortem with them to talk about how the two of you can work better to finding these bugs before deployment. Maybe you can provide them with some queries, or write a little test app to test the load of the system.

Answer 4

First of all, don't panic: bugs in production systems are almost inevitable, and happens to everyone. Users have an annoying habit of finding exactly the wrong way to do something and cause an error message. You're not unusual in this respect.

You should go back at look at the bugs that have been reported against your module, and see what can be learnt from them. Are there any gaps in your knowledge that you should work to fill? Are there any techniques you need to learn, such as how to avoid race conditions? Do you need to do some studying on user interface design, so that it's easier for your users to discover the right thing to do? Are you testing enough? Should you be doing peer-to-peer code reviews? Is it a company problem - should you have a QA team, or are business requirements not being collected properly?

If you can get a handle on the reason for there being so many problems, and do something about it, then next time you won't have as many problems to deal with. I'm sure every engineer has been through this process and discovered something about themselves that they need to do better next time - in my case, I learned that it's never worth doing something "quickly", as it will come back to bite - always do the job in full, properly, first time. Your lesson may be different.

You said you have been developing software for 2 years now - this is not particularly a cause for concern. Truly mastering software development takes years, so make sure you are still moving forward and writing better code every year (or month, or day!)

So, in summary - this kind of thing always happens - but try and learn from the experience so that next time the problem will be smaller, and you will be a better developer.

Answer 5

Quick answer: software is never complete (from code complete)

It is a known fact that after production release, certain number of issues are expected in first months. However, if you get some other serious issues/bugs after 6 month being in production, it sounds to me that it is time to start designing next version.

In next version, hopefully you may consider all concerns of users and address them in one shot. Plus, strong testing strategy needs to be in place to overcome introduction of new bugs.

Some related articles about when is time for Next Release version:

• Version 1 Sucks, But Ship It Anyway
• Wiki - Software release life cycle

Answer 6

A few years ago, I was exactly where you are now. Please see this SO Question:

Is it normal for a programmer with 2 years experience to take a long time to code simple programs?

Its impossible to comment on your competency as a programmer without seeing your work or how well you perform in a team environment. However, the problems described in your question are often symptoms of a much larger organizational problem.

For instance - does your team do any pairs-programming? How about code reviews/standups? Prototyping? Unit testing? It sounds like you're using a waterfall methodology to develop your software -- has your team considered anything agile? These are all tools that can be used to catch bugs before they make it into production code. If they aren't being used, your competency as a programmer isn't in question...but your management's ability to manage software project's certainly is.

If anything, this is a perfect opportunity for you to suggest and build quality control into your group's workflow. The entire group will be better for it, and you could very well come out of this looking like a hero.

Let me recommend two books that jumpstarted my software career:

Pragmatic Programmer - some of the most valuable advice in the book pertains to taking responsibility for your screwups. If you spend $30 on anything this year, make it this book.

Code Complete - Excellent wisdom on how to manage clients and your own management. Also describes several techniques for architecting your solutions in a way that's easy to maintain and cuts down on bugs. Plus tons of general guidelines that make your programming much better.