Training Preparation -- What 100 Attendees Dislike About Software Development

Least favorite thing about dev
Bugs and defects. The challenge and communicating the challenges to others.
Show
Debugging. Hurriedly trying to learn necessary new things. Setting up complex toolchains before making simple progress.
Show
documentation
Show
The misconception by other groups in multifunctional teams that developing software is quick and easy. It is quite easy to walk down the wrong path and write software quickly and haphazardly to produce code that functions for only "right now".
Show
I'm not convinced documentation is as important as everyone says it is. When there's too much, there's a sense of ease but you often miss the important parts. When there's not enough, there's a sense of panic but you can always elaborate more.
Show
no universal rules and good practices
Show
Remembering syntax for languages I don't use very often. Fighting with different IDEs and Debuggers.
Show
When feature creeping gets out of hand
Show
How long it can take to find bugs sometimes
Show
That one renounces quality for reasons of cost.
Show
Limitations by advice / tools.
Show
If time or money are wasted for any reason.
Show
?
Show
It could be paid better.
Show
so many bad code, so many new hypes.
Show
-
Show
I don't like when coding is performed without a plan for the overall architecture and code reuse.
Show
It isn't all exciting- keeping up on new standards and methodologies can be hard to do.
Show
running out of time and deliver unfinished (incomplete and buggy) SW to the customer
Show
running out of time and deliver unfinished (incomplete and buggy) SW to the customer
Show
Nothing comes to my mind now.
Show
reverse engineering spagetti code; long feedback loops for (test) results
Show
Debugging. Sure, I might be the same as the majority (as stated in the intro video), but, yeah, the abyss of debugging can sometimes be a little deep.
Show
bugs - best tester in world taught me to call them mistakes
Show
repetition of implementation and bugs/errors
Show
debugging ;). badly formatted code (different styles from different authors in single file), actually non-tool-formatted code. writing documentation. project managers that trade (initial) development time for quality.
Show
Finding errors/bugs
Show
Feeling on not fully understanding things. Risk of small mistakes having big consequences. The common perception that programmers are already doing the best they can using limited approaches.
Show

Show
Sometimes hunting bugs can be tedious
Show
Sometimes simple things take a lot longer than they should
Show
Documentation
Show
Because you can dramatically change the behaviour of a whole system with very few effort, everybody thinks everything can be fixed by changing the FW
Show
Finding errors/bugs
Show
Packaging, setting up environments, and troubleshooting something to later realize the problem was somewhere else.
Show
the lack of documentation
Show
The search for the cause of an annoying bug that is almost impossible to find out about.
Show
Due to the fact that a lot of people belive that software can always and at any time be changed easily there are most of the time a lot of changes during development. I do not like to fight with a fragmented software that grows and grows.
Show
It is hard to tell if a the way we choose to do things will be considered as a good decision in the future. SW modules always seem to be fine in the beginning as long as they are small and the person who created is available.
Show
Maintaining poorly-written software. Throwing documents over the wall. Doing anything that doesn't add value.
Show
Depending on how the project is lead, it can go wild very easily and the "anything" of above can be changed to "crap".
Show
too many configuration options and unique rules
Show
Lacking of documents. Bad software design.
Show
Writing documentation.
Show
Often solutions are not properly developed because of time constraints
Show
pressing deadline, issues happen last minute require staying late solving it
Show
It's hard to clean up and 'pay' (via code rework) for messes by quick-fixes made in the past. I try to look at it as more of an opportunity to look for ways to not predict the shape of the code beforehand, but make it easy to work with when needed.
Show
Knowledge gets outdated too soon
Show
there is no teammate to review my written software to improve my skills
Show
there is no teammate to review my written software to improve my skills
Show
Long debugging sessions.
Show
Hunting for bugs in poorly written code Weighing up the pros and cons of tidying up poorly written code Making the same points over and over again in code reviews
Show
Difficult to be organized
Show
Having to maintain untidy code and some limitations from the tools.
Show
When you have been debugging your software for hours and find out it's a hardware bug.
Show
Setting up development environment.
Show
Nothing
Show
very old code and not proper documentation
Show
Planning how much time a task may take. Something simple sometimes may surprise you.
Show
Discussions about unimportant details
Show
Maintaining code I don't understand. Often, I don't understand a function until I see it's unit-test. Lacking unit-test I must know all possible ways it can be called, recursively for all heuristic paths, which is improbable. It is scary.
Show
Bloated and inefficient code. Long compile time. Ugly code. Getting many people to agree on a common standard.
Show
Getting stuck with an annoying bug which you can't figure out
Show

Show
.
Show
Not being able to make things behave exactly the way you want it to behave.
Show
(Not) dealign with tecncal debt, restraints on what refactoring activity is "allowed", or there is to much siloing that prevents refactoring and streamlining APIs and integration.
Show
Meetings
Show
When it's slow to test new ideas.
Show
Setup of development system and testing can be very time consuming and frustrating.
Show
Struggling with seemingly random faults, bad structure and I2C.
Show
Time constraints!
Show
It can be very frustrating, specially when we handle hardware that does not behave as expected/intended. So in short: Debugging.
Show
Debugging situations where unknown physical phenomena is affecting the result.
Show
Its sometimes very stressful. When there's a deadline
Show
N/A
Show
.
Show
None.
Show
Deadlines
Show
could get frustrating and time consuming when its dependent on multiple factors and people.
Show
Unclear or changing requirements, prioritizing schedule over quality
Show
Processes (when more effort to check code in, than to write it).
Show
scrum.
Show
N/A
Show
Requirements not being clear at starting, patches to fix requirement mismatch issues.
Show
language complexity
Show
Too much feature requests from the management without a real interest regarding the required efforts.
Show
In my current role of scrum master, there is a lot of overhead to sync multiple topics/ people etc. causing so much of context switches. the software is delivered from multiple teams, so too much dependencies.
Show
Build times, upload times, briefing of management about unfinished states.
Show
--
Show
missing deathlines, documentation
Show
long compiling and test times
Show
Sometimes not easy to understand and debug existing code
Show
Being given incomplete requirements too often.
Show
when I have to use boring tools
Show
Java :)
Show
nothing
Show
na
Show
Not having firm and correct requirements.
Show
Scope creeps late in the game.
Show