Avoiding All Nighter Situations in Software Development [closed]

Question

Trying to understand how experienced programmers tackle programming when they are stuck with a really hairy issues. The situation that I face a few times is like I am stuck with code for quite a few hours, trying to nail down some issue that I don't understand.

The approach that I have tried to get out of the situation are some like:

Change the approach of nailing down the issue. "Comment all code and start by uncommenting a line at a time. Iteratively running the code"

Begin to Think that the issue that I am expecting is not the problem. Something else is!

It's time to talk to someone.

It's probably a data issue.

Of recent my experience has been when I started integration testing as a part of a new development. The test fixture setup was the thing taking most time than actual test case or the development itself. It was like I spent more than 2 days fighting with test setup for a single test class.

Would really help to know how can I reduce the stress involved in such situations. Or have you faced such situations? Or any other thoughts from the Masters? Does facing this issue frequently suggest inefficiency?

Answer 1

Or have you faced such situations?

I don't believe there is a programmer who hasn't spent hours and hours trying to fix a stupid typo.

Does facing this issue frequently suggest inefficiency?

No, it doesn't suggest inefficiency, but rather a lack of discipline during development. There are many studies and techniques for this, and some of them are quite personal, but the point is, the more disciplined you are while writing code, the less likely is to have bugs and to spend a lot of time debugging.

A few tips are:

• Make incremental changes and, after each change, test if the code works (also, look for regressions - check if you haven't broken anything while implementing your new small feature).

• Write tests. There are multiple kinds of tests and development methodologies involving them, starting from simple unit tests written during development up to test driven development. This also helps to automate the testing and quickly check for regressions.

• Write documentation. It makes the code clearer, which may help during debugging. Also, for some people, writing down their thoughts helps clear their mind.

• Criticize your code and try to make it as clear and readable as possible.

• Plan. It is much easier to grab a piece of paper and think a bit about the design of the application, and create a plan following that, rather than being stuck with a mess after some time.

• Have debug messages that can be toggled off may be helpful in some cases.

Basically, the whole point is to write high quality code, that is tested carefully, to catch as many bugs as possible as early possible in the development. But there will be bugs, and the only thing you can do about them is to accept them and plan accordingly. Any good time estimation for software development includes some time for bug fixing.

As for approaches on fixing the bugs, I find them to be a little bit more personal, but I agree that trying to reduce the number of interacting components by commenting part of the code is a valid approach (not always the best, but only practice can tell you more).

TL;DR: Spending lots of time chasing bugs is frustrating and all developers have to go through that. This is simply part of the job. Being more disciplined usually reduces the number of bugs and their severity, but still, you will have to deal with frustration and wasted time.

Answer 2

"Comment all code and start by uncommenting a line at a time. Iteratively running the code"

I do this even today. Well something like it. I comment out all the code. Run. Uncomment half the code. Run. Figure out which half the funny business is coming from. Cut that in half. Rince and repeat. I call it doing a binary search from bugs. It's a tad faster than a line at a time. It's most useful when you find yourself in long procedural methods. Maybe stop writing those.

Begin to Think that the issue that I am expecting is not the problem. Something else is!

When debugging always be willing to learn something. I catch myself wasting time insisting the universe work the way I think it should.

It's time to talk to someone.

Sometimes it's just time to talk. Start with a rubber duck. They're good listeners.

It's probably a data issue.

I never trust anything works until I have a way to visualize data. Why do you think everyone is so obsessed with seeing "hello world"?

integration testing

Of recent my experience has been when I started integration testing as a part of a new development. The test fixture setup was the thing taking most time than actual test case or the development itself. It was like I spent more than 2 days fighting with test setup for a single test class.

Would really help to know how can I reduce the stress involved in such situations. Or have you faced such situations? Or any other thoughts from the Masters ? Does facing this issue frequently suggest inefficiency ?

Integration testing should be automated. Period.

This is sadly rarely followed. Because of that it is hands down the most miserable experience I've had in all of IT (not even simply development).

Integration tests need automated repeatability. Achieving this can test you since at times your programming langauge itself can't perform this. You may need to actually learn how to throw your weight around in your operating system.

I actually learned how to write iDSL's because I was sick of manual integration testing. I wrote a mini language that let me set up everything I needed to run my code exactly as it would be in production. By the time I was done I could easily drop my new stuff into a few expressions that brought the system to life. Sure I could have followed the script, I could have just done it by hand. But dammit I'm a programmer not an operator. I did this to a system that wasn't even designed for this kind of testing.

Truthfully what I had was an end-to-end test. This didn't touch the gui and it was happening on my development environment. But so many configuration bugs were happening because the manual testing was a nightmare I just had to do it. Setting it up took time. But man did it pay off.

Now you can get third party tools that brag they can do this crap for you but no one knows your system better than you do. If you're thinking there has to be a better way, there is. You just have to care enough to do it.

Answer 3

If you want to eliminate all-nighters, just go to bed when you are tired.

If your boss / manager thinks software is made better by rushing to meet a deadline, they are wrong.

Either find a different employer that knows something about how to treat its employees properly, or simply go to sleep when you are tired and return to the problem the next workday.

Answer 4

Avoiding all-nighters in software development starts with planning and proper estimation technique. In many cases, if you're still coding last minute, it's because the effort was underestimated or not really addressed up front.

You're certainly not alone -- every developer has faced this kind of situation. The time to talk to someone is often in the very beginning, running your proposed approach or design against someone else, to get their opinion.

When estimating, don't assume the best-case scenario or the worst, but consider the possibility that your technical approach may be wrong, and what additional activities you'd need to do to solve that problem. Make sure you have factored in unit testing, integration testing, and defect resolution.

Iterative running the code, as you describe, can be a good approach when troubleshooting -- simplifying and isolating the problem area so you can detect the specific issue.

Writing tests, as in TDD, can really help in this scenario as well, because it makes you work a little at a time, verifying your functionality as you go. As you build more tests, it's easier to tell when and where your code has broken.