31–40 of 41 posts
Building something (with great effort) then tearing it apart because the product team decided to go a different way. Over and over again.
Bikeshedding during code reviews
Number one has to be the idea that software development can be outsourced to save time. It takes the same amount of man-hours to develop the software plus about 40% more to manage the relationship with the outsourcing firm. Then another round of contracts/specifications/budgets/bs to fix the things that weren't in the original spec.
Number two is the idea that some people are just too important to get involved in specifying a product but they'll certainly tell you that you have done it all wrong two days before release. I may be a little bitter about that.
- Before committing, clean things up by removing a debugging statement and some whitespace
- Bug reappears
- Undo the cleanup
- Bug remains
It's amazing how often this happens. It usually takes a good half hour to find what's actually wrong. A good indication that you're close is that your development environment will mysteriously hang or your house wifi will go down. That's the universe putting in its one last shot at wasting a little more of your time before giving up and letting you win.
- Make a change that fixes a bug - Before committing, clean things up by removing a debugging statement and some whitespace - Bug reappears - Undo the cleanup - Bug remains It's amazing how often this happens. It usually takes a good half hour to find what's actually wrong. A good indication that you're close is that your development environment will mysteriously hang or your house wifi will go down. That's the unive…
Earlier quoted context omitted.
What do you mean "networks disconnect" and "hardware fails"? I have no idea what you're talking about.
I can give you an example. I inherited a system which, on a scheduled basis, completed the following, in order: * Drop a database * Rebuild that database from REST queries The process took under a second and the "downtime" was acceptable. However, if there was ever a short connectivity outage, or the upstream was down, the result of that was that the database was dropped and inaccessible for 24 hours until the next s…
Reminds me: on a project I was on, we created some tests where we manually pulled the network cable out of some PCs (on a client-server LAN app), to check whether the app at least gave a reasonably appropriate error message instead of just hanging. Fun times.
This tends to include many of the things listed by others here, like not having estimates accepted at face value (because they don't understand development), lack of communication of business goals (because they believe developers just implement, they don't understand "product"), lack of consideration of developers' ideas (see last), deadlines without input from development (because developers will inflate their estimates)... But for some reason, developers can't just learn management, they have to find someone "skilled" from the outside, technical understanding be damned.
Requirements churn