Training Preparation -- What 100 Attendees Dislike About Software Development

Least favorite thing about dev
Process
Show
NA
Show
-
Show
Repetitive tasks
Show
process
Show
Time taken for compilation and sometime load on target
Show
Preparing documents( HLD, DLD)
Show
Nothing much.
Show
Long compilation cycles
Show
Coding without having a proper Design. Not taking care of impacts of software.
Show
Preparing the exact simulation environment to avoid testing on hardware is difficult.
Show
nothing
Show
Complexity as and when features increase, managing is difficult. Need to make sure no regression
Show
how to test software
Show
how to test software
Show
NA
Show
I don't know to be honest, sometimes it's just boring when I have to re-implement something existing
Show
Develop feature, which had incorrect prepared tests.
Show
Extensive testing
Show
Everything, especially the constant humiliation
Show
Documentation.
Show
Engineers don't talk much and lack the pleasure of communication.
Show
debugging, incomplete requirements, undefined behavior of code
Show
Finding bugs.
Show
Fighting legacy code
Show
Being deep in the debugging process and not knowing what to do resolve it.
Show
The overhead - documentation, design meetings, etc
Show
Setting up infrastructure for development, debugging the tools instead of the code
Show
Debugging hard to reproduce problems. Spending time trying to hit weird edge cases.
Show
Without understand system
Show
Getting into something over my head.
Show
Getting into something over my head.
Show
Using someone else's API or tools that are poorly documented
Show
Bugs
Show
dealing with buggy tools, dealing with legacy code...
Show
schedules
Show
When you can't figure out why the computer won't do what you want!
Show
pressure
Show
Debugging (mainly, not knowing how to debug).
Show
Distractions
Show
Dealing with changing requirements
Show
Finding causes of bugs and fixing them.
Show
When algorithm that seemed good in my head does not work in code as expected
Show
- Wasting tons of time drudging through legacy code - Breaking brittle code - Poor architecture
Show
- When debugging takes too long - When there is too much code to wrap my head around
Show
Esoteric/time wasting bugs
Show
Analysis Paralysis. It's easy for me to spend too much time trying to find the best architecture.
Show
The short schedules to achieve unreasonable accomplishments
Show
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