For a previous job long ago, I spent several months off and on working on an obscure and difficult-to-reproduce bug, without success. A year after I was laid off, a customer encounter a clear reproducing case, and I came back for a day to work on it. The fix was one character: < vs <=
You've only added two lines – why did that take two days?
281–290 of 522 posts
Re: You've only added two lines – why did that take two days?
#282Earlier quoted context omitted.
What happens in case where specification is: [User inputs X1, system displays Y] On system crash user input was X2. Is this specification or program logic error ?
I generally consider system stability an assumed part of the specification. Your system should handle most input errors from users more gracefully than a crash. Specifications are never as detailed as the program. So a description of what it should accept implies what it shouldn't. The questions for the programmer when faced with invalid input are: 1. Should it crash? (almost always no) 2. Should it process the garba…
If I understand correctly, specification describes "what/when" and program logic describes only "how".
Re: You've only added two lines – why did that take two days?
#283This article made a number of great points. > I know some developers don't like having to fix bugs, and so do whatever they can to get out of it. Claiming there isn't enough is a great way to look like you're trying to help but not have to do anything. God, this behavior has annoyed me so much at times. I've worked with a few developers that were not bad overall, but would use the slightest excuse to punt on fixing a…
> Regularly weaseling out of tasks like this wastes the time of multiple people and either ends up back with the original dev or gets dumped on a more responsible worker.
A lot of this depends on the environment and circumstances. If you're in the middle of working on feature X it's very annoying to have to drop it to look at a bug, sometimes it's necessary but usually it can wait. This is where having great user support comes in too, capturing what the user was doing, getting relevant logs and knowing how to reproduce are important and if you don't have a good support team that falls to the developers.
The other big factor is external pressures, if you have management asking for frequent updates and putting pressure on to get through tickets quickly (especially common at consultancy type shops) then bug fixing is miserable high pressure work that I will avoid at all costs. An environment without those and bug fixing can be fun, give me the biggest most spaghetti like enterprise system and no time pressure and it feels like getting paid to solve a giant Sudoku puzzles all day.
While we're all swapping war stories I'll share my most epic 2 line fix at a place were I was afforded the time. I was working on this huge mess of over abstracted, multi threaded, spaghetti enterprise OO, trying to track down a bug that happened maybe once a fortnight. I tried narrowing it down to reproduce but nothing was working, the stack trace was about 15 levels of indirection away from the trigger so the most I could narrow it down to was hundreds of thousands of lines of code. After a couple of weeks of trying things and getting nowhere I told the boss we'd probably never track this down but they insisted I keep trying. Eventually I wrote a script to copy all the logs locally where I could search and do some analysis on them, after grepping 18 months of logs I noticed that on 3 or 4 occasions the same error was happening within 5 seconds of each other. From there it was a matter of finding "Sleep(5000)" in the code to know exactly where the error was. Turns out that 15 levels of indirection was quite slow and getting a stale piece of data we already had anyway so the time wasted turned into a nice little improvement.
The scripts for the logs become invaluable too. So many times we got "you incompetent idiots broke x with your last update" we could reply a minute later with "x has been happening since , you only just noticed".
Re: You've only added two lines – why did that take two days?
#284This is a great write-up. This is real life.
And then you get a corporate dude berate everyone and ask: what are you doing to make sure that it never happens again?
And I always want to respond that "I can guarantee that the same thing won't happen again, but something very similar will happen, if you won't assign sufficient resources to fix the real problem, instead of putting on a band-aid.
And you won't even know the difference."
I think the OP covers this case very well.
Re: You've only added two lines – why did that take two days?
#285Earlier quoted context omitted.
Early in my career, I learned a simple 'demo day' rule: never demo things that aren't end-to-end done. When you do, it can easily confuse folks who aren't deeply involved in your project ("haven't I seen this already?") and can hurt team morale because they never get a "shipped it" moment that feels good. More to the point: enforcing this rule incentivizes teams to build things in small, shippable components. Nobody…
Also, never use the word "done" in any context in a meeting like that. Do not even say: "I'm not done". They won't hear the "not". Say, "Development is still in progress" or something similar. I got chewed out for something being released (where it was found to be broken) to a customer because I said something like: "I'm about 80% done with testing, but I haven't run into any issues yet." They released it even though…
I think I've spent most of my mentoring time in various careers teaching new folks that the worst thing you can say is "done, except for".
Re: You've only added two lines – why did that take two days?
#286Because the code is architected like a Jenga tower.
Re: You've only added two lines – why did that take two days?
#287Earlier quoted context omitted.
Did you really get chewed out? That seems pretty much like a deal breaker for me. Managers are collaborators, not parents, and have no place talking to co-workers in such a diminutive manner.
Yes. He came to my desk a week or so after he okayed the release of the software and took me to a conference room. I don't know how long he chewed me out for because I was red with rage but too terrified of losing my job to say anything. I've experienced similar rage with only one other manager [1]. He was 3 levels above me in the management chain, I really liked the two above me (the test manager, as I was in test a…
Reading your comment reminds me of how sheltered and lucky I've been in my career. If my manager released something after I said I was 80% done with it I'd go have a talk with him about how "we" can avoid making that mistake again and what process needs to change to prevent similar errors.
If he tried to chew me out, I'd just say "That's not how I remember things. I said I was 80% done, and, frankly, it was a mistake for you to pull the trigger on the release without confirming with me first."
Re: You've only added two lines – why did that take two days?
#288Had a PM ask why we were taking so long to build a future-proof platform when this other team over here built an emergency project in 3 weeks.
Had to explain that that project was held together with duct tape, not one bit of it was reusable, and even the engineers who build it were saying it was shit.
Re: You've only added two lines – why did that take two days?
#289Earlier quoted context omitted.
In a company that understands and embraces agile software practices, this works well. You demo small things that are done, and prototypes are understood as just mockups designed to drive future work. Alas not everyone in power gets it. In more egregious cases, I've been in adversarial environments where teams were pitted against each other to appear "more done." Obviously a recipe for failure. I'm fortunate enough to…
I've been with a few companies that waterfall in two-week cadences and call it Agile... They usually expect a fully working demo
There's no greener grass on the other side.
I've been in the big consulting business, and sometimes you can't get a client to schedule a meeting for months, so you're flying blind, with absolutely no feedback.
And then we go into the typical cycle of "Lessons Learned" etc, because what you've developed is irrelevant to the client.
Re: You've only added two lines – why did that take two days?
#290Had a PM ask why we were taking so long to build a future-proof platform when this other team over here built an emergency project in 3 weeks. Had to explain that that project was held together with duct tape, not one bit of it was reusable, and even the engineers who build it were saying it was shit.
I would've loved to be a fly on the wall in that meeting.