Training Preparation -- What 100 Attendees Dislike About Software Development
| Least favorite thing about dev | |
|---|---|
| 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 |
| When the project requirements change over time and don't match the original functionality the code was written for. The design is no longer the most efficient or elegant way of solving the problem but you don't have time to start the project over. |
Show |
| Tracking down difficult bugs. |
Show |
| cleaning up after others |
Show |
| I do not like the limits of the IDE or the simplistic languages used for our PLC development. |
Show |
| Post-sale support |
Show |
| Sometimes the problems make my head hurt and I can't seem to work out how to fix issues. |
Show |
| Changing Requirements |
Show |
| Software bugs. |
Show |
| I don't like it when the logic becomes too complicated to think through clearly, or too hard to test. |
Show |
| testing |
Show |
| n/a, manager. |
Show |
| bugs that get past QA and end up in the field |
Show |
| The process of releasing a software into production. |
Show |
| debugging |
Show |
| Unsure |
Show |
| Developing prototype code is easy. Developing production code is hard as it needs to meet certain standards. All the processes associated with developing code to a certain level of quality are a burden to developers when they cannot be streamlined |
Show |
| Debugging |
Show |
| Poor requirements leading to code redesign and implementation. |
Show |
| The amount of test, debug time necessary to make basic code devoid of bugs, and operate smoothly, from a users perspective. |
Show |
| debugging hard to find issues |
Show |
| Trying to develop something when the requirements are unknown / vague / ambiguous. |
Show |
| analog effects on expected results of programming. |
Show |
| Too many languages around :) |
Show |
| Stake holders that tell how to write code to meet a requirement instead of stating the requirement. Usually preceded by "Can't you just" or "All you need to do is". |
Show |
| Manual regression testing. "Working" on software when the new hardware is flaky. |
Show |
| Working with convoluted legacy code at times (which has underlying unexposed vulnerabilities) |
Show |
| Spending lots of time trying to reproduce corner case issues. |
Show |
| I only perceived what I did not like about a year ago, when I heard about Uncle Bob and TDD: I'm always tense, afraid of rotten, fragile code. It feels that only I could handle it. As I got ill (4 years in bed), this became even more dreadful. |
Show |
| Using wrong tools. Try to use a code for days and finaly find that it's not working.
|
Show |
| Uncertainty of what is needed, changing requirements.
Dependency on other parts not always in your control (libraries, hardware, etc.) |
Show |
| Probably the unknowns that can be time sinks away from valuable development |
Show |
| Troubleshooting code at the debugging phase |
Show |
| Not having a disciplined approach to software development and not having enough experience at it. |
Show |
| Development processes can be a bit tedious. |
Show |
| Not always understanding the entire system, and having unexpected factors cause problems. Also, having to be very pedantic about small issues in reviews. |
Show |
| nothing |
Show |
| Finding faint bugs (those that "sometimes" happen) |
Show |
| I don't like the unpredictability and stress associated with debug-later development. I feel like SW testing is under-valued in the embedded sphere, and I see many instances where it would have saved a lot of time and money. |
Show |
| I don't like settings up new tools. I feel like it is hard for me to discover something new and be efficient with it. I usually take time to get used to something. |
Show |
| I don't like spending whole afternoons hunting bugs that are caused by minute mistakes in code implementation ! |
Show |
| myself making stupid mistakes |
Show |
| Debuging
|
Show |
| Changes in existing code can be quite difficult if its not your own code |
Show |
| debug is always struggle |
Show |
| Being stuck at one problem for a long time. |
Show |
| Often lonely endeavour.
Bit nerdish |
Show |
| Sometimes also the range of possibilities we have ;)
When software is some kind of unwanted. |
Show |
| Working on legacy code (brown field) without having the chance to make it better. |
Show |
| - Compile-time.
- Debugging bugs, especially those, which are easily overlooked |
Show |
| Debugging |
Show |
| I don't like when classes are too much inter-depend, eg when you have to include many header files to develop your feature. |
Show |
| Waiting for the code to compile.
Unclear error messages. |
Show |
| If timeline does not provide the time for refactoring old code or sufficient testing cycles. |
Show |
| Requirements that are not systematically prepared. "Request concert" |
Show |
| searching errors.
trying to understand confusing code |
Show |
| testing |
Show |
| Waiting for the compiler to finish. |
Show |
| missing understanding of non concerned people about the complexity of that...
|
Show |
| - more and more difficult tools and tools to wrap tools
- real working together reduces when the team increases |
Show |
| Clustering in coding standards/style, bad testability and everything else that makes me invest more time in understanding what existing code is doing instead of woriking on a problem/bug/feature. |
Show |
| Bug fighting, especially if the bug is not reproduceable |
Show |
| I don't like to leave work when something is not working. And I hate how systems become complex over time due to added features. |
Show |
Make this into a word cloud
Select text below (triple click), copy, then try one of these tag cloud generatorsjasondavies word cloud generator - colorful
tagcrowd - lets you show counts