Ask HN: What are the most annoying things in software development?
As a software developer, which tasks do you find most annoying in your daily work? Which part of your job would you like to outsource to someone else if you could?
- 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.
Having to tell others (contractors, collaborating 3rd parties, etc.) what they shall do and how to do it. We've got an issue tracker and a TODO list and tons of TODO/FIXME/XXX comments in our code base. How about working on those? Pick an issue in the tracker (or if you've found some TODO/FIXME/XXX that hasn't assigned a tracking ID, create a new own) and work on it! Oh, and please don't ask me for a pinned down specification for each and every detail; it takes me more time and work to write down such micromanaging specs, than it'd take me, to write the code myself.
You think meetings are productivity killers? At least you can zone out in those and mentally work problems. People asking to be micromanaged, that's what really grinds my gears.
...Waiting for tests to run
...Waiting for code to compile
...Waiting for someone to return an email / message / text / whatever
...etc
I probably don't actually spend that much time waiting everyday. But when I do have to sit and wait for something, I go nuts.
Over and over again.
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.
1. Too many requests for an NIC to handle,
2. Certificates expiring,
3. Firewall changes closing an active port down,
4. A router failing,
5. Congestion, interference in wireless networks resulting in excessive packet loss.
Hardware failing- HDDs, RAM, routers crashing, cables at datacenter being accidentally unplugged, racks being misconfigured during upgrades, maintenance etc.
See slide #4 here- http://static.googleusercontent.com/media/research.google.co...
The idea that everything can and should be done in JavaScript.
I know the parent comment was sarcastic, but it reminded me of this trend.
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 scheduled run.
I'd put forward that we build a new database first and then, only if successful, perform a swap. Maybe we could implement a retry. But then came the response I knew I was going to see: "Well if your network's not reliable hire competent network admins that's not my problem".
In a sense they were correct, it wasn't their responsibility to ensure the network doesn't ever drop. It was however, their sheer laziness that led to repeated service outages.
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.
The most frustrating is when I am completely convinced a change I make is going to resolve some failed tests, and then I run the tests, and something still doesn't work. Or I fix something and cause another problem. I enjoy the challenge of getting everything right, but just feel betrayed when I'm convinced I do it right and I'm wrong.
Can't outsource that, though. What I would love to outsource is the actual writing of the testware. I like thinking up all the test scenarios, but wish I could do a brain dump and have someone else write the testware.
The other thing I wish I could outsource is any documentation creation or review. Probably because I can think a lot faster than I can write, and then also feel like I have to take extra time to document things precisely because I might not be able to have a dialog with whoever is reading the docs.
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.
E.g. "In Version 1.0, it will talk to these 3 services only..."
But that is different from 'requirements' which I take it as 'things that are required' and have a non-negotiable connotation about them.
E.g. "It must work with all of our services"
Since it is not know which requirements are actually required and which are BS, it may be better to call requirements 'requested functionality' and what is planned to be delivered 'project scope' and drop the requirements word altogether.
Never do I here, oh we are thinking of going in this direction. What do you think?
Rather it is "We ARE doing this, and we need to get it done in 2 months, how can you make it happen?"
Either your company has a bad culture, or your Product Manager doesn't believe in a collaborative process or you are not working for a small enough company. :-)