
Ask HN: What are the most annoying things in software development? - ThePhysicist
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?
======
jasonkester
\- 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 universe putting in its one last shot at wasting a little
more of your time before giving up and letting you win.

~~~
eecks
I don't think that has ever happened to me. There can be stuff like caching or
hot reloads working/not working in your favour but if the bug is fixed, it's
fixed.

------
datenwolf
> As a software developer, which tasks do you find most annoying in your daily
> work?

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.

------
bbcbasic
As a developer it seems I am subordinate and I am not privy to any business
decisions or direction which is information that is not communicated, and we
are often not consulted.

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?"

~~~
eshvk
> As a developer it seems I am subordinate and I am not privy to any business
> decisions or direction which is information that is not communicated, and we
> are often not consulted.

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.
:-)

------
MalcolmDiggs
Waiting. Just in general. Waiting tends to piss me off

...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.

~~~
insoluble
If you work on or manage Windows machines, then waiting for Windows Updates
can really suck. This may not seem directly related to programming, but it can
be when you have sandbox virtual machines that are perpetually non-updated
after being reverted to previous snapshots, or when you often break operating
systems. Virtual machines make for an IT Groundhog Day.

------
nstart
Fighting to get my estimates accepted. I try as often as possible to give good
estimates. This seems to always mean mine are a little longer as I don't give
optimistic timelines. I get pushed back to shorten timelines and I'll sit on
my head refusing to do so. This is almost always when it comes to dealing with
obscure bugs. It's very difficult to give a timeline for those, so after
digging around and trying to find the root of the problem (or at least a
general direction) I give an estimate of a few days (3-5, sometimes 7) for
that. Fighting to have these estimates accepted is painful. It's especially
annoying because one is made to feel like long estimates are an indication of
slacking off. Everywhere I've been it's the same thing. It feels like a
bargaining exercise at your local street bazaar. Not fun. Also, mildly
demotivating for a short period of time.

------
what-no-tests
Building something (with great effort) then tearing it apart because the
product team decided to go a different way.

Over and over again.

~~~
AnotherMarc
Ugh, you need a new product team if doing that is the norm. It's gonna happen
sometimes, but shouldn't all the time. Maybe you can push back on them before
getting too far into the builds, force them to think through things a little
deeper?

------
andymurd
Oh how many things there are that annoy me. Here are just two:

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.

------
jnpatel
Bikeshedding during code reviews

~~~
hanniabu
What's bikeshedding?

~~~
killerdhmo
LMWTFY
[https://en.wikipedia.org/wiki/Parkinson%27s_law_of_trivialit...](https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality)

------
taprun
Sitting in meetings that had nothing to do with me

~~~
onedev
Then just don't go to those meetings. Problem solved.

------
infamouscow
Convincing software developers that networks disconnect, hardware fails, and
data gets corrupted.

~~~
onedev
What do you mean "networks disconnect" and "hardware fails"? I have no idea
what you're talking about.

~~~
technion
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 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.

~~~
vram22
Nice story.

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.

------
ljw1001
Scrum (especially the estimation/tracking cycle), and the people who inflict
it on you

------
AnotherMarc
Some things here (meetings, bad managers, etc.) are all too true, but not
unique to software development/developers!

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.

------
awaythrow101
Non-technical direct management.

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.

------
hga
Dealing with incompetent managers.

------
bambang150
Content development, Small bug, yeahh something like those things that
required some time. And also, image fixation requires more time than it should
be lol

------
velikos
Requirements churn

~~~
ThePhysicist
You mean e.g. requirements that change over time or requirements that get
added during the project?

~~~
hanniabu
Both would be somehwat equally annoying in that they change the scope of the
project.

~~~
bbcbasic
Requirements are like deadlines. Made up things to keep us controlled.

~~~
bsg75
Requirements keep management controlled, exposing them to the concept that
change has cost (manager here).

~~~
bbcbasic
Setting the scope of the work is what is keeping management controlled.

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.

------
lgieron
Scrum meetings. Hard to outsource though.

------
camhenlin
Dates and times

------
Aeolun
Encoding issues

