Training Preparation -- What 949 Attendees Dislike About Software Development
| Least favorite thing about dev | |
|---|---|
| Documentation (other than code comments), spending too much time testing. |
Show |
| Can be stressful. |
Show |
| x |
Show |
| Variety, Creative Independence |
Show |
| Being hurried to get it done without thorough testing, covering all use cases. |
Show |
| Testing |
Show |
| Bugs and debug |
Show |
| Bureaucracy involved in some of the process steps we have at GE. |
Show |
| Trying to schedule its development time. |
Show |
| death marches
poorly structured code |
Show |
| having to debug and fix defects that no one can reproduce. |
Show |
| Nothing |
Show |
| Challenges |
Show |
| Maintaining poorly documented or rambling patched code |
Show |
| I don't like having to conform to old or outdated standards. |
Show |
| debugging |
Show |
| Waterfall model of software development |
Show |
| At Zebra, have not been given the opportunity to design prior to coding |
Show |
| I least enjoy API design as it can be frustrating to get the right balance of simplicity and flexibility. |
Show |
| Too many untrained developers. |
Show |
| Non-trivial projects are enormous and generally old. Standards change and newer developers will modify improper pieces of code. |
Show |
| Debugging multithreaded code. |
Show |
| Poorly defined requirements |
Show |
| zxczc |
Show |
| No major dislikes. |
Show |
| Deadlines |
Show |
| much thinking and much testing . |
Show |
| Code Maintenance |
Show |
| Sometimes some very small issues take up too much time trying to find out what went wrong. |
Show |
| too much process. |
Show |
| - |
Show |
| When there's a bug and it's very difficult to find it out |
Show |
| vice versa |
Show |
| I don't like dirty |
Show |
| Testing |
Show |
| Computers are dumb. The only do exactly what you tell them to do. Lots of bugs to catch. |
Show |
| build time too long |
Show |
| Testing |
Show |
| It's difficult to find bugs. |
Show |
| repetition |
Show |
| The frustration when the development process is not going as fast as expected. |
Show |
| Debugging |
Show |
| Process |
Show |
| Using different tools to test and compile the code. Slow build time and lack of debugging tools |
Show |
| when there are too many screwed up unknown dependency |
Show |
| object oriented |
Show |
| long build times |
Show |
| Debugging.
|
Show |
| when build server is down, build need longer time, requirement is not clear, do not have test targget to test, too much of process. |
Show |
| different hardware environment or different system environment between developing and running. |
Show |
| too much process to govern the software quality, debugging software |
Show |
| review processes |
Show |
| Debugging non-deterministic low level embedded software issues. |
Show |
| 1 |
Show |
| bug and error |
Show |
| Hidden bugs that only show up months later |
Show |
| Debugging. |
Show |
| - |
Show |
| Waiting for code to build. It takes 2-3 minutes every time I clean my code on CCStudio. |
Show |
| embedded software has limit resources, often we have to have some hardware ready in order to test or implement a functionality. Some problems that we see (like complete lock-up issues or driver lock up issues) are not repeatable |
Show |
| poorly written legacy code |
Show |
| Being dependednt on hardwar whose workings I dont know |
Show |
| Testing the code which we know will work , but sometimes not thinking through the code where it impacts other systems. |
Show |
| takes time to debug |
Show |
| Hard to say, it gets to my gut sometimes |
Show |
| Debugging other peoples code with sufficient debug messages |
Show |
| if jobs becomes repetitive and documentation. |
Show |
| Tight dead lines. |
Show |
| Time spent on not doing the real thing |
Show |
| Debugging unknown code written by the open source community with the "sparse" comment style. |
Show |
| Bad code. |
Show |
| Overheads and paperwork |
Show |
| Tracking down those elusive bugs for too long. |
Show |
| You can get stuck in the most simple bug for hours... |
Show |
| Writing documents (SDD) |
Show |
| NA |
Show |
| Spending time continually debugging everyone else's code and not writing anything. |
Show |
| Too much emphasis on process and not on effectiveness of code and results |
Show |
| Having to come up with high confidence predictions for large pieces of complicated programming work... |
Show |
| It doesn't happen fast enough |
Show |
| DO-178B flight certification requirements for following a more Waterfall flow. Resistance to testing first because it hasn't always been done that way. I don't like that DO-178B requires independence (code developer can't be the test developer). |
Show |
| Getting bogged down fixing weird bugs. |
Show |
| The ability to effectively predict time to capability availability |
Show |
| almost nothing |
Show |
| Not having all the requirements when I start. |
Show |
| Someone sitting on my shoulder |
Show |
| debug |
Show |
| Documentation |
Show |
| nasty bugs (timing, memory or multithreading problems that can consume significant effort) |
Show |
| Problems that are difficult to get to the bottom of. |
Show |
| Wasting time debugging simple errors |
Show |
| Facing numerical problems like the loss of significance. |
Show |
| Have to do with inherited messy code |
Show |
| Tricky debugging |
Show |
| documentation |
Show |
| the intriccies of the language |
Show |
| Mundane but necessary tasks. Tracking down bugs. Maintaining bad code. |
Show |
| Documentation... :) |
Show |
| jumping through all the hoops to get code checked in |
Show |
| nothing really |
Show |
| Debugging others' code. |
Show |
| - |
Show |
| too many meetings and not spending time on development |
Show |
| Difficult to track hardware interactions, trouble getting consistent results |
Show |
| Fighting with the tools to get them to do what I want them to do. |
Show |
| All the BS management stuff. |
Show |
| Hard bugs. It's a love - hate relationship. |
Show |
| Being patient with management. |
Show |
| It has been 10 years since I worked on a project that has actually shipped. Seems most companies cannot tolerate the amount of time it takes to build something from scratch. |
Show |
| Debugging, especially in embedded environments. |
Show |
| Tedious processes. |
Show |
| Check-in process |
Show |
| Dealing with buggy or inadequate environments. |
Show |
| - |
Show |
| Yes |
Show |
| interruptions & managers |
Show |
| boring solutions that take a long time to test |
Show |
| I don't particularly like debugging (most of the time) |
Show |
| Not having the correct tools to properly test the software |
Show |
| tool crashes |
Show |
| The big amount of legacy code, which is badly written and not understandable. |
Show |
| Maintenace work of old not documented code where no tests are available. |
Show |
| repetition, ugly code, hungarian notation, tricky code without clear design and responsiblity. Non exisiting model. |
Show |
| I don't like when you fix some bug in a part of code and create another one , or maybe more than one , in some other part. |
Show |
| Writing the documents |
Show |
| Trying to find those bugs that turn up in the field. |
Show |
| Runtime errors which can't be reproduced. And that they always come up when it is no time to analyse. |
Show |
| People that don't communicate and don't like to clarify anything. Non passionate people about programming. |
Show |
| nothing till now |
Show |
| Debugging code for bugs after release. In simple word post release bug. |
Show |
| - |
Show |
| Getting blocked by the "company" |
Show |
| n/a |
Show |
| finding the starting point of how and what to code. |
Show |
| debugging |
Show |
| Lousy tools |
Show |
| Tedious debugging. |
Show |
| test and documentation |
Show |
| debug. |
Show |
| I don't like sitting and staring at a screen of text all day. |
Show |
| reading code with no comment, improper idents |
Show |
| Hard to set up. Questions like this |
Show |
| Frustrations with tools on occasions. Sharing resources when needed. |
Show |
| Really long debug sessions, working with buggy, undocumented legacy code bases |
Show |
| Issues caused by tool limitations that I have no control over and have to work around. |
Show |
| Not much really other than having to sit at desk all day. |
Show |
| Project politics, redirection from above, poorly stated and/or shifting objectives. |
Show |
| cannot control other people's activity, for example, your product architect, your testing team, even if you do a good job, other people could still screw up the product |
Show |
| coding |
Show |
| creating something new |
Show |
| Inability to use a debugger, forced to use printfs |
Show |
| schedules, lol |
Show |
| None. |
Show |
| Slow environments |
Show |
| Integrating code changes into the larger code base. Many code developers running pre-commit tests that have intermittent failures. |
Show |
| Meeting, Meetings, Meetings - I attend all the bug reviews and do the initial triage on the bugs reported by other groups. |
Show |
| making changes in other module code |
Show |
| Tools that don't work |
Show |
| Getting around hardware hard bug, dealing with unexpected and critical timing issues, specifically un-reproducible bugs. |
Show |
| na |
Show |
| Failing. |
Show |
| Switching between platforms can be a painful, grueling process. |
Show |
| Working with legacy code that is not well documented and difficult to test. |
Show |
| Debug and test. Fixing problems after they get to the field. |
Show |
| testing |
Show |
| When we get a customer complaint, and I have to try to figure out what code (that I probably didn't write) is doing, while being pressured by management |
Show |
| dealing with managers who don't understand software |
Show |
| Too much documentation |
Show |
| Nothing really |
Show |
| when inconsistent errors occur |
Show |
| It can be hard to follow another's code, particularly if they do not write organized SW. |
Show |
| Meetings, distractions, constant pressure to under-estimate how long things will take to design correctly. |
Show |
| Reading/debugging other people's code |
Show |
| Undocumented APIs, excessive management overhead, pressuring schedules and last minute changes |
Show |
| Not much really. Perhaps when 3rd party tools are crashing/buggy and/or shaky requirements. |
Show |
| 1. Weak hardware. More's law seems to stop when it comes to embedded hardware.
2. Legacy code. |
Show |
| I do not like when things are going very slow. For example, the customer is not answering problematic questions etc. |
Show |
| Static working position. |
Show |
| Debugging errors others have made |
Show |
| messing with log files and looking for errors |
Show |
| I hate that very often I have to fix and clean up untested sloppy code written by other (often more experienced) developers. |
Show |
| When I release SW with a bug that I wrote a unit test for...
Race conditions... |
Show |
| somethimes stressfull |
Show |
| new specificaitons in the last minute |
Show |
| Unclear specifications, changing opinions, |
Show |
| Errors that show no clear pattern .. of course. |
Show |
| Messy code from others. |
Show |
| It always takes more time to finish than anticipated. |
Show |
| Parts of the documentation and planning before starting |
Show |
| deadlines :) !! |
Show |
| efficiency for problem solving |
Show |
| not sure |
Show |
| Debugging |
Show |
| Debug time and tools - especially gets harder when there are more components involved; integration is likely bound to be affected, unless the code is carefully written/implemented. |
Show |
| requirement not clear |
Show |
| Find tricky bugs, work on dirty code base. |
Show |
| ... |
Show |
| I use hardware platform. |
Show |
| NA |
Show |
| no comments in code, no coding standard |
Show |
| There are always bugs in the code, and some of them often bothers me for weeks. |
Show |
| It's lonely |
Show |
| no |
Show |
| n/a |
Show |
| nothing |
Show |
| no |
Show |
| limited test |
Show |
| No |
Show |
| Impossible deadlines and expectations. |
Show |
| having to tolerate people that are not good at it |
Show |
| I can't always use the languages I'd like to use. |
Show |
| Waiting for computer/tools.
Bugs in tools. |
Show |
| Documentation |
Show |
| Spending hours to find where the bug is. Spending a lot of time trying to get the environment working, rather than the business logic. |
Show |
| Error handling, testing, documentation (reading and writing), eye strains of staring at the screens, interacting with other people |
Show |
| pretty much everyone else's coding style; working on a poorly written code base. |
Show |
| Dealing with shortcuts taken in the short term that negatively impact long term software quality. |
Show |
| Mysterious bugs; hardware anomalies. |
Show |
| na |
Show |
| Debugging code that is not mine. |
Show |
| Intermittent bugs |
Show |
| some times not efficient when editing |
Show |
| Its been a while |
Show |
| documentation |
Show |
| The changing of requirement that cause changes in the automated test scripts |
Show |
| Cost! It is tough when you are bound by cost. You need a $3 CPU and you are given a $1 CPU. |
Show |
| Not having the information to understand the goal of writing the test. |
Show |
| Release to production process |
Show |
| debugging other people's code |
Show |
| don't like to be rushed, usually results in half baked solution |
Show |
| Bugs. |
Show |
| There is a risk with any software deployed in large quantities that a bug will cause serious problems. |
Show |
| Meetings, pressure to fix bugs or complete features in short space of time. |
Show |
| changing requirements |
Show |
| multiple releases |
Show |
| new languages |
Show |
| Nothing really. It usually the politics of code changes near a release that make I don't like. |
Show |
| easy to change so business can often add more and more features to releases that already have challenging schedule |
Show |
| Bugs |
Show |
| Documentation can be tedious. |
Show |
| kalimba dev environment |
Show |
| See above. |
Show |
| Dealing with careless and untidy code |
Show |
| Random results when testing on real hardware, working on hard to follow or rotten code. |
Show |
| Humans. |
Show |
| I think we spend too little time writing code, instead we seem to have to spend lots of time maintaining technical debt, and 'fire fighting' problems that arise in the most remote corner conditions. |
Show |
| Fighting with tools and development environment. |
Show |
| When I haven't got software to develop. |
Show |
| Fighting toolchains |
Show |
| Dealing with crappy existing code |
Show |
| Struggling to fix issues in legacy code |
Show |
| Integrating new code into old code |
Show |
| To understand/work on legacy code which is not documented or not very well designed. |
Show |
| Documentation, meetings. |
Show |
| Trying to fix bugs caused by careless planning and design reviews. |
Show |
| Building the setup for cross-compilation, and deploying |
Show |
| Spending a long time debugging a problem and finding it is a one-line fix that should have been picked up earlier. |
Show |
| Having time pressures |
Show |
| -Bugs!!! |
Show |
| Honestly, I don't like doing regression testing after writing software |
Show |
| Debugging |
Show |
| Manual test, especially when it have to be done more than once. Software components without source code or documentation/examples. |
Show |
| nothing really, wouldn't be a software engineer if i didn't like doing it. |
Show |
| Deadlines |
Show |
| got stuck when debugging, frustrated when can't find the bug or solution |
Show |
| Depending on other's code. |
Show |
| Debugging |
Show |
| Debugging. |
Show |
| Technical friction, bugs, untested software, wasting time debugging, accumulation of technical debt, flaky tools, wasting time debating with co-workers, dealing with people who don't want to (or don't know how) to change. |
Show |
| Dealing with immense technical debt. |
Show |
| Being out of the zone. |
Show |
| Less observable and debug-able than hardware |
Show |
| Determining what a customer really needs vs what they think they want.
Arguing with management about priorities, especially around tooling, refactoring etc. |
Show |
| Debugging |
Show |
| Painting yourself into a corner with bad design decisions. |
Show |
| I don't like looking deadlines when there is a tough problem in my path to the finish line. |
Show |
| Repetitive changes, fear of regression due to enhancements. One of the reasons for joining this course if it can automate UT as much as possible. |
Show |
| the tedium still associated with the assembly and configuration part of development. It's amazing how far we've come and yet how much BS we still put up with. |
Show |
| existing software |
Show |
| stress |
Show |
| Working with preexisting code |
Show |
| learning new technology |
Show |
| Debugging poorly written code or mysterious bugs that often appear to be problems with things like the OpenGL video drivers we are stuck with. |
Show |
| Trying to make sense of another developer's code, especially when said code contains functions consisting of hundreds of lines of code. |
Show |
| documentation: it is challenging to keep it up to date with the software that's constantly evolving and is time consuming |
Show |
| Some of the politics required when making a design decision and the amount of testing required to prove the design out (with no unit testing) |
Show |
| Lack of knowledge and understanding of software development by rest of company |
Show |
| TBD |
Show |
| Suppose this is optional. |
Show |
| Fighting with tools and poorly written code. Bureaucracy. Solving the same problem over and over. |
Show |
| changing or misleading requirements or last minute requirements. |
Show |
| bad IDE |
Show |
| N/A |
Show |
| Troubleshooting other people's poorly written/designed code |
Show |
| Flexibility / Rapid results |
Show |
| Brainstorming initial stages |
Show |
| I don't I the useless complications and the non commented codes |
Show |
| Documentation |
Show |
| nothing |
Show |
| Nothing |
Show |
| writing tests and debugging |
Show |
| Documentation (Yes, I know that is necessary) |
Show |
| Writing Documentation |
Show |
| Inadequate requirements capture
Not having target HW or FPGA platform to develop embedded code with. |
Show |
| When bug reports come back from the field and engineers must work hard to identify and fix the problem in very short time. That is a very stressful period. |
Show |
| Branching and merging.
'Big-bang' integration.
Requirements capture is painful, requirements sign-off is almost impossible.
Mentoring and teaching others... |
Show |
| Changing requirements |
Show |
| testing |
Show |
| Testing corner cases |
Show |
| that stupid random bugs that you aren't able to replicate |
Show |
| delving into somebodies else code |
Show |
| time pressure |
Show |
| I don't like sitting too many hours per day in front of a PC. I don't like headaches caused by uncontrolled software. |
Show |
| Sometimes management does not understand the software developments process and might pressure you for unrealistic results |
Show |
| the risk of bugs |
Show |
| Talking about what to do for too much time. |
Show |
| manual testing |
Show |
| Debugging, because it oftenly takes much time |
Show |
| ? |
Show |
| Changing requirements |
Show |
| Bugs are usually very silly .. and done by me. |
Show |
| make sw tests |
Show |
| bugs |
Show |
| Complexity |
Show |
| if software testing has hardware dependency |
Show |
| Technical debt getting lower priority than business requirement in regular planning. But this technical debt may result into bigger problems if ignored for long. |
Show |
| s/w that is not documented, s/w not debuggable |
Show |
| Sometimes I get bogged down during the design phase trying to find the perfect solution, drilling down too deep. |
Show |
| Unnecessary complex coding and untested code |
Show |
| Documentation |
Show |
| Dealing with bad legacy code. |
Show |
| Documentation |
Show |
| Alot of folks dont really know how to design or develop code |
Show |
| That it is so malleable---thus can change easily which then brings it's associated issues. |
Show |
| then i wouldnt be in this training. |
Show |
| Rutine |
Show |
| NONE |
Show |
| NA |
Show |
| Be tied to very complex code (hard to understand and to reuse) because the projects are already in a mature stage and big changes are not allowed |
Show |
| We sometimes have lacks in the requirements from the client, and sometimes the requirements that are very well specified do change several times. This is normal and we live with this. |
Show |
| The time spent investigating bugs due bad designs |
Show |
| I don't like running tessy for my code. |
Show |
| Testing |
Show |
| When you find code which is not documented, is illegible, weak, and try to fix it. |
Show |
| Surveys. |
Show |
| spaghetti code |
Show |
| When an issue comes up that causes long debugging times and late hours. |
Show |
| It can be a challenge in not perfect environments |
Show |
| Project managers and scrum masters who seem only to want to check off their boxes, not deliver actual good software to customers. Also, I dislike when software engineers design UI's - this usually results in bad usability. |
Show |
| Debugging with less info. |
Show |
| Maintaining and developing over something that is built by somebody else. Need to know , visualize and assume which sometimes could be wrong. |
Show |
| unexpected crash |
Show |
| Finding duplication. (Though removing it can be satisfying.)
Working out real requirements when there aren't any that are coherent. (Again though that can be satisfying when complete.) |
Show |
| Testing |
Show |
| Having to rework my implementation because someone will not sign off the code review until it has been done in they way that they would prefer, not because it would make the code any less error prone or more maintainable. |
Show |
| sitting in front of computer the whole day, no physical activity |
Show |
| Short deadlines meaning I don't always get time to design and write in the best way |
Show |
| Not much really. The aspects I don't enjoy are mainly organisational and political. I don't really consider those "developing software". |
Show |
| The way in which I am forced to do things I don't think are sensible |
Show |
| Maintaining poorly written code without supporting test cases.
Repetitive manual tasks.
|
Show |
| Effort going waste |
Show |
| Sometimes having to maintain other people's legacy code |
Show |
| Mainly maintenance, debugging the issues which are not easily reproducible. |
Show |
| . |
Show |
| . |
Show |
| Too much sitting still. |
Show |
| Not knowing where to start when attempting to dive into a new, large subject |
Show |
| I am yet to find that part... |
Show |
| Usually have to move faster than I would if I didn't have to keep a client happy |
Show |
| Hard to comprehend bugs that make you feel like you're going insane. The boring work in between writing code. |
Show |
| Yak shaving |
Show |
| Frequently changed the requirements and debugging. |
Show |
| having to maintain/fix spaghetti-code in the name of business interest |
Show |
| There is rarely time to write good code for a product. There is too much pressure to get something out the door *now*, irrespective of whether it can be maintained or extended in the future. |
Show |
| Not much, actually except when I have to work on some one else's code or work in an area that is uninteresting to me, e.g. GUI code or data protocol analysis (L3/L4). I'm a low-level embedded software engineer. |
Show |
| Dealing with legacy code |
Show |
| Lack of thought put into designs |
Show |
| Fixing problems in other people's code. |
Show |
| hmm mostly the delays and lags preventing me from being efficient(ide, development environment, build times, testing, boot times). I also hate compromising on code quality for meeting a deadline. |
Show |
| the minutia of cross platform issues, steep learning curves |
Show |
| The hours of manual test and regression testing existing code for product release. |
Show |
| Things often do not work. |
Show |
| Working with existing code and trying to get things to "fit" cleanly. Trying to understand poor abstractions in existing code. |
Show |
| Getting bogged down trying to fix bugs. |
Show |
| Layers of useless process, information duplication, shoehorning. |
Show |
| Misunderstanding of what we do from the rest of the company, though that's getting better. And of course, the odd bug that only happens once in 10,000 occurrences. |
Show |
| Testing, but I want to learn to love it, just like I want to learn to eat my vegetables, since it seems like it is a "healthful" way to work in the long run and I might even get to like it eventually. |
Show |
| N/A |
Show |
| There is no 1 proper way to do anything, everything has pros and cons to it and can make things really difficult on figuring out what is the best action. |
Show |
| Timelines are too short to properly document the process. |
Show |
| Code tends to become untidy or obsolete too fast. |
Show |
| Trying to figure out what somebody else did, especially when their code is arcane, poorly written, or not done the way I would do it. |
Show |
| Deadlines. |
Show |
| scheduling, waterfalls. |
Show |
| Having to do all the legacy manual testing we have. |
Show |
| When stuck debugging complex problem |
Show |
| Support |
Show |
| - limitations of the languages.
- some clever guys that write code that only they understand (or think so).
- bad code
- bad tests (that take forever to run, fail intermittently and were done to make the code to pass. |
Show |
| Can't think of anything except for providing time estimates ;-) |
Show |
| The reluctance to sometimes change bad processes. |
Show |
| anything that isn't pure design, coding or analysis of existing code, for example: setting up the environment to work with for the first time, reporting progress to project managers, etc. |
Show |
| Not enough time spent actually coding! |
Show |
| Modifying code I don't understand |
Show |
| Taking ages to make decision |
Show |
| Grappling with complex test setups which often don't work reliably |
Show |
| Repetitive tasks. |
Show |
| Nothing |
Show |
| Coding can be mundane at times. |
Show |
| Having to type so much to get something done (particularly a problem for c, hence the use of perl and more recently python). |
Show |
| When I have to go through and fix bugs in legacy code which is not well commented and documented. |
Show |
| may not be fun |
Show |
| Difficult question. I don't think I dislike anything about developing software |
Show |
| Bugs due to cut and paste the code |
Show |
| Maintaining poorly documented code where the author assumes the reader will understand the intent.
Maintaining 'scruffy' code that does not conform to even the most basic of formatting and indentation rules. |
Show |
| Unstable sw and hw development platofmrs |
Show |
| Testing. |
Show |
| frustration of time spent compiling, loading, debugging to achieve goals. End to end time. |
Show |
| Time pressures |
Show |
| Other peoples code |
Show |
| Dunno |
Show |
| challenge! |
Show |
| long requirement and design cycles. Somehow it stops you to try early prototypes. Or sometime end up forcing you to write which is bound to not to work! |
Show |
| Being interrupted and context switching to other peoples problems... |
Show |
| Bad code layout. |
Show |
| In some cases testing is very time consuming and debugging even more. |
Show |
| changing requirements that mean work needs to be reworked. |
Show |
| bugs |
Show |
| Badly written, untested, unreadable code. |
Show |
| Can be frustrating when things don't work. Uneasy feeling of unintentionally breaking or introducing bugs with code changes. |
Show |
| When it is hard to understand what is happening. |
Show |
| Not much. |
Show |
| Everybody likes to shortcut and not do things the right way or cleanly. |
Show |
| That we don't have a lot of strong software developers at the company and I often feel as though I'm stumbling in the dark. |
Show |
| Discussions about details. |
Show |
| too much arbitrary convention to learn |
Show |
| When different ideas about how writing software collide. |
Show |
| The are too many things to mention, but you have to take the good with the bad. |
Show |
| When I don't feel competent frequently enough. It's self-reinforcing and I have to bust out of that spiral, usually by clearing my head enough to pick something small and easy that I can competently do. When I succeed, that's self-reinforcing too. |
Show |
| There is so many ways to solve a single task, or worse design a system. This leads to endless discussion. |
Show |
| Meetings.
Time schedules.
Maintenance.
Correct answer is probably testing, but I thing testing is mostly fun. Its like baking a cake (coding) and actually taste it afterwards (testing).
Ok, repetitive testing is not so fun. |
Show |
| Poorly thought out requirements that come in verbally. |
Show |
| Paying down another vendor's technical debt. |
Show |
| 1) Writing condensed code that may run fast but is difficult to understand. 2) Manual integration of code from different teams 3) Only manual testing |
Show |
| slow compile times, old toolchains, crappy debug-interfaces. |
Show |
| I don't have many technical problems. Most revolve around working with people, managing my own levels of motivation, and capturing / delivering / communicating customer needs. |
Show |
| When management is indifferent to the welfare of their employees. |
Show |
| Other peoples code |
Show |
| Documentation |
Show |
| When we give up on the design and future changes / debugging is difficult. |
Show |
| Debugging |
Show |
| Debugging legacy software |
Show |
| Working with team-members that don't appreciate quality code and good practices/processes. |
Show |
| The messes that people make (including me). |
Show |
| Reviewing others code.
Debugging linking problems.
MISRA-C (MISERABLE-C) picky or arcane errors.
Fixing others poor code. |
Show |
| Blind hatred or love of 'agile/scrum' while simultaneously misunderstanding it. Monolithic schedules that change all the time. Not wanting to invest to get more efficient or use new tools. |
Show |
| issues that aren't reliably reproducible (mainly race conditions) |
Show |
| When I don't understand why something is not working the way I expected it to. |
Show |
| Working with legacy code, investigating customer bugs |
Show |
| There are frustrations in any endeavour but nothing jumps to mind. |
Show |
| Pointless paperwork |
Show |
| I takes a long time to figure out that I didn't actually tell the hardware to do what I wanted it to do. |
Show |
| When I have to debug code written so poorly that I have no clue what's going on. This typically leads to too much time spent on debugging leaving the feeling nothing has been achieved. |
Show |
| Almost the same as why I love it: There is so MUCH to learn, and so much change, that it becomes VERY tough to keep up with new techniques and tools. |
Show |
| Assembly language |
Show |
| see above |
Show |
| Interruptions and distractions |
Show |
| I don't like code that people describe as tricky or where the author wants to focus on how obscure their solution is for little or no functional gain. |
Show |
| Configuration |
Show |
| Nothing |
Show |
| Where to start. Like other disciplines, the blank page is the most troublesome part. |
Show |
| Dynamic |
Show |
| Repetitive |
Show |
| Testing. |
Show |
| Figuring out why things that should work don't |
Show |
| Things sometimes don't always behave as expected. |
Show |
| Debugging other peoples code when they do not care to make their code easily maintainable. |
Show |
| After 20 years in the business...still haven't gotten it right. |
Show |
| I never seem to be given enough time to develop embedded software correctly. There is always code I would love to re-factor if I was just given a little more time. |
Show |
| Overhead. |
Show |
| Manual testing. Using third party API's that is either undocumented, or does not work as specified leading to countless hours of trial and error and support requests. |
Show |
| The environment it is embedded in (or I am actually embedded in. Don't know.): Price and time pressure, unreasonable expectations and demands.
Manual procedures like going through test lists, release creation, ...
|
Show |
| When a colleague / tester shows me an error and I get that "Oh no, I hadn't thought about that. This is going to be a complete nightmare to fix and I will need to have a complete rethink. |
Show |
| Spending time generating waste.
Working on legacy code (even my own!), by legacy I'm using Michael Feathers definition. |
Show |
| Any situation where I get stuck on a problem for a long period of time and can't figure out why something doesn't work as expected |
Show |
| With developing software, we are required to deal with new last minute requirements and come up with workarounds. This leads to last minute bugs and some timing issues, which require the system to be completely retested, even for minor updates |
Show |
| It's up to the SW developer to prove that the problem is with the HW. |
Show |
| hard to reduce the time spent debugging because of bugs that are not catch a head of time |
Show |
| Going round trying to get to the bottom of the requirements |
Show |
| too much sitting |
Show |
| syntax errors |
Show |
| implementation |
Show |
| Parsing input and gui development |
Show |
| Can be tedious |
Show |
| stuff |
Show |
| time spent on testing |
Show |
| writing documentation |
Show |
| It strains my eyes when I look at the screen for too long every day. |
Show |
| The overhead time before a single line is written (especially relevant when you are working on a simple system that uses both microprocessor and integrated FPGA fabric) |
Show |
| Testing |
Show |
| It's never finished, there is always something that could be better. |
Show |
| naming is hard, code generation sucks and is used way too much in embedded, embedded tools are in the stone ages compared to web & mobile |
Show |
| tightly coupled codes |
Show |
| Time taken to root cause failure.
Trying to understand code that is not structured well or readable. |
Show |
| That you have to sit at a desk all day |
Show |
| When build systems/configurations fails. |
Show |
| It's easy to make fatal mistakes. |
Show |
| Doing it under timepressure |
Show |
| Writing ugly fixes due to time constraints. Working in code that should have been refactored long ago. |
Show |
| That our instruments (target) vary between individual to individual. |
Show |
| When you gets an unimaginable bug. |
Show |
| na |
Show |
| bugs, carelessness, cost of going back to fix really simple errors that should have have existed in the first place. |
Show |
| Time and effort taken to root cause an issue (reproducing the conditions that lead to it). |
Show |
| I like developing and nowadays I don't get much chance |
Show |
| complexity of tools, code. |
Show |
| Defects that appear Friday at 5pm. |
Show |
| - |
Show |
| - Manual testing |
Show |
| Thinking sw is malleable and can take-up all work-around for HW team issues |
Show |
| -- |
Show |
| Code that is hard to understand (eg legacy code that is monolithic)
Debugging issues that should have been identified early in the development lifecycle.
|
Show |
| Developing software with bigger teams is difficult. |
Show |
| - Many times we cannot predict results especially in real time environments |
Show |
| More bugs.. |
Show |
| Documentation. |
Show |
| too many bugs |
Show |
| debugging, digging through documentation to understand development software tools. |
Show |
| ?? |
Show |
| My own lack of understanding. I'm sure most of my issues are solved problems. |
Show |
| Its frustrating when people who dont understand much about embedded systems ask for changes/features that are extremely difficult to implement. |
Show |
| Patching,debugging |
Show |
| debugging other developer's codes |
Show |
| Poor Documentation... |
Show |
| take over some bad design existing code and fix bugs |
Show |
| Figuring out how/where to make changes, resolving merges, and integrate libraries. |
Show |
| When the code does not perform as expected , even after I've debugged it. |
Show |
| Tracing low-level issues. |
Show |
| Constant interruptions. Fear to change things. The overwhelming amount of bad code out there. |
Show |
| Portability of code between different hardware types is never seamless. Takes ages to debug. |
Show |
| Debugging really low level errors (silicon errors and interrupts) |
Show |
| The amount of time spent on fixing bugs. |
Show |
| Legacy code that sucks. Difficult to find spontaneously combusting bugs. |
Show |
| involves working on code someone else might have written and you dont necessarily agree with the design approach |
Show |
| NA |
Show |
| Not much chance for physical exercise. |
Show |
| The tool and system set up |
Show |
| It is also fun to understand how each developer is unique and the thought process is different to resolve a given issue. |
Show |
| No two programmers are the same !!! |
Show |
| If the issue doesn't get solved or no roo cause find. Or the code is very hard to debug |
Show |
| Sorting out issues/glitches in test environment. |
Show |
| When working in big teams it is difficult to maintain the quality |
Show |
| debugging |
Show |
| Lack of clear goals. Assumption is code change are easy |
Show |
| No comments |
Show |
| Time munching coz of different tools and depedencies |
Show |
| In large projects I don't like if there are too many external libraries involved over which you have almost no control. Bugs. |
Show |
| Many hours spent because of one stupid bug |
Show |
| - debug, fix code from other programmers.
- hard to catch bugs - difficult to reproduce.
- start programming from the scratch. |
Show |
| Potential for failure, bugs that show up once released. |
Show |
| I do not earn enough money. |
Show |
| / |
Show |
| Fixing legacy code or maintenance |
Show |
| debugging |
Show |
| waiting for builds and test runs |
Show |
| Nothing ever works first time. Maybe TDD can help with that :-) |
Show |
| It can get complicated at times. |
Show |
| Technical debt building up in code or test harnesses. |
Show |
| see above |
Show |
| The time pressure |
Show |
| Nothing that I can think of, except dealing with Sales/Marketing! ;-) |
Show |
| Nothing so far |
Show |
| Debugging it. |
Show |
| I don't like repetitious work unless it is a one-time thing. |
Show |
| I don't like routine coding. |
Show |
| constantly being forced to use someone else's crappy code |
Show |
| na |
Show |
| debug |
Show |
| Time constraints |
Show |
| Other people's code. |
Show |
| there are two many processes when you are working in a huge project and many other works other than developing. |
Show |
| debug |
Show |
| when it just started |
Show |
| Writing a piece of code never gets executed.
Writing throwaway codes.
|
Show |
| many environmental issue happens and blocks development |
Show |
| Not applicable. |
Show |
| The stress that comes with the job |
Show |
| repeated codes |
Show |
| Debugging memory corruption issues |
Show |
| Resolving external dependencies. |
Show |
| Bugs |
Show |
| Living with old existing poor design |
Show |
| When code doesn't work because of some feature I do not know about |
Show |
| Nothing |
Show |
| Paperwork and manual tests. |
Show |
| Having to maintain poorly written code. |
Show |
| The associated paperwork |
Show |
| I hate it when our customers have bad experiences with our products because products were deployed with bugs. |
Show |
| Changing requirements, working with legacy processors, and obviously over-buggy code. |
Show |
| I guess the final stages or maintenance...taking care of the more trivial things |
Show |
| Bugs, and testing. In hardware, you can just change a capacitor to change that RC filter, without worrying about negative overflows and untested boundary conditions. In firmware... |
Show |
| Debugging |
Show |
| When the code does what you tell it to, but it isn't what you expect. |
Show |
| Debug other people's code |
Show |
| Requirements definition (people are always changing their minds) |
Show |
| debugging |
Show |
| Documentation. |
Show |
| Spend too much time on debugging.
Spend too much time on setting up test environment. |
Show |
| supporting multiple platforms ;-) |
Show |
| Red corporate tape. |
Show |
| Having too many people working on the same code and maintaining different products with a lot of branches. Spends a lot of time in merges and resolving conflicts. |
Show |
| That the requirements and priorities of the software changes quite often. |
Show |
| Others code ;)
On a serious note, I hate trying to convince the managers or the group that code review and unit tests is time well spent. |
Show |
| documentation |
Show |
| dealing with legacy code |
Show |
| No particular dislikes |
Show |
| Things that don't work |
Show |
| documenting |
Show |
| When the embedded C just doesn't work for no apparent reason |
Show |
| Probably dealing with product managers and sales teams. |
Show |
| I dont always know if the module is safe enough and is the hardware i am developing functioning properly. |
Show |
| Becomes too routine sometimes. |
Show |
| Going back to fix bugs. |
Show |
| Difficult debugging, and in particular that it is literally impossible to estimate how long it takes. |
Show |
| Working with code that is messy. |
Show |
| when the newly created things turns out to be monsters :) |
Show |
| restructuring and changing unorganized existing software |
Show |
| That you're sitting inside, staring at a screen all day |
Show |
| Writing tons of boiler plate code over and over again |
Show |
| The paper work that is required with Medical Device software |
Show |
| Currently: the verbosity of Java
In general: writing lots of boilerplate code before doing anything productive |
Show |
| Nothing, its beautiful ;) |
Show |
| n/a |
Show |
| Analysing bugs |
Show |
| When non reproducible problems occur, which cause much troubleshooting or debugging... |
Show |
| repeatedly manual testing. |
Show |
| Unexpected changes (either hardware or software), just before a release. |
Show |
| Tedious sometimes. need more automated tools. Unclear specs. I work as a lone cowboy with the rest of the company in. China. Every body should work as a team. This is an organizational issue I attempting to work on.Learn a |
Show |
| Tedious sometimes. need more automated tools. Unclear specs. I work as a lone cowboy with the rest of the company on another continent. Every body should work as a team. This is an organizational issue I attempting to work on.
|
Show |
| ongoing changes, working with many people and we aren't aligned on how to get things done. |
Show |
| Repetitive tasks |
Show |
| I don't like when I get stuck with debugging or fixing bugs, especially intermittent bugs! |
Show |
| Flaws in human interactions that are involved in code, such as incomplete/lack of requirements because people are too lazy to spend time preparing a document or to review them, etc. |
Show |
| NA |
Show |
| Debugging and refactoring legacy code. |
Show |
| The repetitive testing |
Show |
| It's hard. |
Show |
| Process overhead. we have few processes that we have to go through to submit the code. there are lot of overheads which i dont like in software development |
Show |
| debugging. |
Show |
| Weird bugs in the code that are very hard to track down sometimes. |
Show |
| Being stuck with other people's crappy design choices. |
Show |
| Complexity can quickly spiral out of control. Hyper-nonlinear, tiny code changes can have massive impacts to the behavior of the code. |
Show |
| Fighting against bureaucracy. |
Show |
| Restrictions placed on dev environment by IT |
Show |
| Not being able to crack the problem at hand and move forward. I detest being stuck, while developing software. |
Show |
| searching for bugs, rewriting SW |
Show |
| Tedious Syntax |
Show |
| Annoying bugs |
Show |
| The short time schedules and ambiguous requirements. |
Show |
| Often a difference between how I would like things to be done and reality.
Planning accurately is very difficult! |
Show |
| Stress |
Show |
| Manually perform regression tests |
Show |
| Bugs |
Show |
| Difficult debugging |
Show |
| Nothing |
Show |
| Sometimes it does not work as I have planned. |
Show |
| Having to write things in a rush, taking shortcuts |
Show |
| When tools are not appropriate for the job at hand and thus frustrating to use. |
Show |
| To solve the same problem again and again. |
Show |
| being stuck |
Show |
| . |
Show |
| C++ programmers (or more precisely those who taught them to create the bad code they write) |
Show |
| Fluid requirements. |
Show |
| when I know how to solve a problem but am not allowed to or not given the tools to do so; when too much is done manually that should be automated |
Show |
| Having to work with bad code |
Show |
| Having to deal with nuances of languages, environments, configurations, etc. |
Show |
| bickering |
Show |
| Lack of variety |
Show |
| Boilerplate code |
Show |
| if not fit in above. |
Show |
| Not understanding certain things. |
Show |
| Moving targets. |
Show |
| Maintaining old, undocumented, critical code. |
Show |
| Not understanding why a fix to the code made it work. |
Show |
| I don't enjoy when things become overly complex and when debugging becomes the main task. |
Show |
| From the product side of things, it's the same ole story, I can't have it created for me fast enough :) |
Show |
| N/A |
Show |
| I'm a little tired of embedded. Specifically, I'm a little tired of cross compiling everything and the resource constraints. |
Show |
| Legacy FW, covering a multitude or projects, so must always keep doing things the same way to avoid breaking targets that we can't test locally. |
Show |
| Unclear documentation |
Show |
| 1. constantly changing priorities and requirements.
2. Interruptions
3. Big |
Show |
| Difficult development environments. |
Show |
| Nothing really. |
Show |
| When tools are flaky or slow. |
Show |
| Going to meetings and arguing about what the code should do.
Making changes to products from 1 or 2 years ago (especially adding new features to old products, which is worse than fixing bugs in old products) |
Show |
| Deadlines, inevitable scope-creep |
Show |
| Can be mundane |
Show |
| Code tends to get complicated over time. |
Show |
| Mature, ugly code that everyone is afraid to refactor |
Show |
| Large organizations spend a lot more time communicating than doing things. I don't enjoy the communication so as much. |
Show |
| Anything that is not productive and slows me down. |
Show |
| time to debug and testing is more than actual coding because of legacy code. |
Show |
| having to learn some one else's complex code |
Show |
| Can't think of anything now. |
Show |
| Setting up development environments, especially getting all the dependencies working. |
Show |
| Getting stuck because of a stupid bug. |
Show |
| the business aspect |
Show |
| Incomplete or inconsistent user manuals for hardware |
Show |
| Sometimes it can be very frustrating/stressful/tedious. It's hard sitting in front of a computer for so long! |
Show |
| Defects |
Show |
| Figuring out the right dev environment |
Show |
| Documentation |
Show |
| Can be tedioius |
Show |
| Deadlines! |
Show |
| Sometimes boring/stressed |
Show |
| debugging other developer's code |
Show |
| Sometimes solutions are obscure and feedback can be few and far between with small to nonexistent positive reinforcement. In short, it can be very tedious sometimes if you work on stuff for a long time with little positive progress |
Show |
| Resolving inter-team communication issues. |
Show |
| old crappy code |
Show |
| n/a |
Show |
| Trying to reproduce a bug and not being able to |
Show |
| physically sitting around most of the time and reading through very old code. |
Show |
| When requirements are amorphous. |
Show |
| I don't like working on poorly designed and written codebases. |
Show |
| I don't like interpreting code without comments or unhelpfully named variables. I don't like writing tests. |
Show |
| Dealing with code that comes from previous "questionable" decisions and design (or lack thereof). |
Show |
| Dealing with code that is as old as me |
Show |
| Poor development environments (long build times, poor debugging tools, etc.) |
Show |
| all the initial setup to get to point where you start writing code. |
Show |
| Looking at undocumented code I didn't write and trying to understand how it works. |
Show |
| When the problem is too easy. |
Show |
| - |
Show |
| Head-ache debugging. Someone else "messing" up my particularly neat code. |
Show |
| Watching the user get frustrated. |
Show |
| Not sure. I like developing software. |
Show |
| debugging |
Show |
| Running into issues beyond my knowledge or having harsh deadlines. |
Show |
| Testing |
Show |
| Atthis company, I don't like customizing a code base I know nothing about, and have no knowledgeable resources to bounce idea's off of. We don't know the overall design/ application of design patterns, ect... |
Show |
| Poorly written code. I see too much of it. Clean code makes everyone's life much easier. |
Show |
| When political obstacles get in the way. |
Show |
| Debugging bugs |
Show |
| tedious |
Show |
| Having bugs on the field.
|
Show |
| Being bothered |
Show |
| hard to debug intermittent errors keeping you up at night. |
Show |
| Digitally Signing Drivers for Windows |
Show |
| The only thing worse then programming is not to program. |
Show |
| Beeing slowed down by crappy tools. |
Show |
| Bad tools |
Show |
| Dealing with legacy code that wasn't written well. |
Show |
| Don't get to be out in the sunshine |
Show |
| Over-reacking processes and software that has little structure. |
Show |
| Long Build Time, not having coding standards. People that think they know it all... |
Show |
| ? |
Show |
| When same code fails multiple times on multiple paths |
Show |
| Not enough time spent on it. |
Show |
| working with developers who don't collaborate/communicate, don't test their code; working with developers who care more about code than about the impact of that code on the product they're developing code for |
Show |
| Sitting at a desk for extended periods of time. |
Show |
| some aspects of agile |
Show |
| nothing |
Show |
| Difficulty in getting good specs & reqs.Management & schedules. Reteaching that software is not always that simple. Documentation. Proving that it's not always software - sometimes electrical issues/hardware. |
Show |
| nothing |
Show |
| Process overhead |
Show |
| The agile process and company process sometimes get in the way of being able to do productive work, like fixing bugs, and replace it with tedious work like typing up SCRs, PBIs, etc. |
Show |
| excess documentation |
Show |
| That there seems to be a never ending wave of new technologies that do the same thing just a little little differently, but offer little value over prior art. |
Show |
| configuration and administrative type problems, for example not having rights, having to figure out the exact version of some 3rd party software to use |
Show |
| I don't like when it takes forever to test something
I don't like long build times
Fixing bugs that should have already been fixed.
|
Show |
| It can be frustrating. |
Show |
| I do not always enjoy acquiring requirements and editing code based on changed requirements. |
Show |
| dealing with third party software problems |
Show |
| IDE's and low level setup of the registers. |
Show |
| Trying to give estimates for how long something will take. |
Show |
| explaining computational complexity, tell-don't-ask, and other software paradigms to non-software folks. Also the limitations of cross-compiling are annoying. |
Show |
| Regression testing. |
Show |
| Coming up with and documenting test plans isn't much fun. I also become extremely grumpy when all the other groups make unscheduled, undocumented and unannounced changes to my test machine when I'm trying to qualify brand new code functionality. |
Show |
| Schedules that don't allow for things to be done right! Politics. |
Show |
| Dependency on hardware. |
Show |
| it is my job |
Show |
| Too much to learn
Easy to get lost in the details |
Show |
| The "invisibility" of software which is less recognized by people outside of the embedded community. Also, in embedded software (which requires a target hardware for testing), it is difficult to run automated tests for TDD purposes. |
Show |
| Searching for the cause of bugs. |
Show |
| Exhaustive testing is time consuming |
Show |
| Asking estimates, hearing about bugs from customers |
Show |
| see it not working by someone else |
Show |
| Having to debug/edit someone else's code which doesn't follow any standard or is of poor quality. |
Show |
| Debugging the tools |
Show |
| Good question, maybe too many formalism |
Show |
| unstable or limited tools |
Show |
| I don't like having to work with third-party code because it usually means that any issue found will take ages to be fixed. It's also always harder to debug because it has no consistency with the company code. |
Show |
| . |
Show |
| Some time it is hard to finish something to the perfect outcome. |
Show |
| When the requirements change after a significant part of the design or implementation is complete. |
Show |
| --- |
Show |
| - Ecounter many mistakes after compiling the code. In particular, ecounter mistakes, that require a significant amount of time to debug.
|
Show |
| Read the code written without care. |
Show |
| Producing documentation to check off that it was produced. Much of what external standards and the FDA require us to produce, if done correctly, will help us write better, more maintainable, software. This is rarely done well or valued.
|
Show |
| Struggling to figure out what a method does. Worrying about the unknown rationale for why a method was implemented, and concerned that I might break that. |
Show |
| There's not much I don't like about developing SW. Probably the amount of time spent on DV testing and documentation. |
Show |
| Having to load the code on the machine to test it, we don't have a simulator. |
Show |
| Separate reporting structures are used hide behind scheduling and system issues. |
Show |
| Only having VectorCast to do unit test (which means I don't do unit test). UGH! |
Show |
| --- |
Show |
| Remaking systems do new things because someone didn't tell me the correct requirements up front |
Show |
| People forcing unit testing on me |
Show |
| Pressure to get things working quickly |
Show |
| I do not enjoy using code which I do not fully understand. |
Show |
| The bugs, all the bugs. |
Show |
| Can be frustrating to implement new tools that are suppose to help the coder develop efficient code. |
Show |
| It seems that sometimes things are deliberately difficult when it seems possible to be done in a simpler way. |
Show |
| Trying to understand or debug someone else's labyrinthine code, then not being allowed to rewrite it. |
Show |
| When it doesn't work |
Show |
| Fighting my tools, non-standard and confusing environments, poorly architected legacy systems that are a pain to extend or debug without massive amounts of overhaul, occasionally having to write software documentation in Microsoft Word. |
Show |
| Sometimes it can be tedious or repetitive. |
Show |
| I hate fighting tools. Fixing something in one tool shouldn't lead to a break with another, but sometimes it does. |
Show |
| Manual Testing and writing unit tests for classes/methods that are not written with unit testing in mind. |
Show |
| creating large amounts of documentation beyond the code itself |
Show |
| Documentation for safety critical software can be time consuming. |
Show |
| Not always knowing how best to solve a problem with the most clean and direct code. |
Show |
| Fighting with the tools |
Show |
| Having to use Stack Overflow and dealing with arrogant, pompous, opinionated individuals; many of whom do not fully answer the question and do not exhibit patience towards those learning. |
Show |
| Sitting inside all day has some serious disadvantages. |
Show |
| Maintaining legacy code. |
Show |
| Having to deal with pathologically bad products that I cannot change. |
Show |
| debugging |
Show |
| - Gnarly toolchains & infrastructure
- Other peoples' commits breaking my code |
Show |
| Trying to remember specific syntax when switching between many languages, trying to remember all the various libraries available to use. |
Show |
| Test code generation is not automatic. Testing is only as good as one intended. How to test code in an unexpected way? |
Show |
| The delays of a slow build/startup/test cycle, how long it takes for code to get reviewed. |
Show |
| Time lost to slow builds and ineffective processses |
Show |
| Waiting for a build to finish. Taking ownership of legacy code with no tests. Wasting time debugging. Developing the wrong thing. |
Show |
| Sunk cost fallacies |
Show |
| Documentation! and maintaining code that is a mess and untested. |
Show |
| It's very hard to prove that you're doing exactly what you say you're doing. Doing so is time consuming. Legacy code. |
Show |
| Chasing erratic bugs that consume large amounts of time to reproduce. |
Show |
| Accurate requirements gathering from our typical clients (small company, mechanical engineering types) has been incredibly painful, historically.
Managing dependencies is also never fun. |
Show |
| The overwhelming amount of communication and process involved as team size grows |
Show |
| There are too many tools available and not much good information. Good non-beginners content is hard to find. |
Show |
| (Head) Managers how don't know what's the problems of hardware, software, software development,and that we are humans. Those, who don't want to know that it will take time to develop/make good products but will save money afterwards |
Show |
| Hard to get third party stuff to work. Configuration problems. Figuring out legacy code. |
Show |
| Poor quality everywhere, and seeming lack of concern over it. Teams complain they "don't have time" to do it any better. Teams responding to my suggested improvements with "we know we should be doing that", yet they never adjust. |
Show |
| Solving un-challenging, yet tedious problems. |
Show |
| Just how bad we are as an industry at developing software.
Seeing Complex, organic, unmaintainable code get written, and not having the ammunition to fight it. |
Show |
| 2 |
Show |
| Failure to anticipate a use case that requires a significant redesign. Ideally sw is flexible enough, but sometimes difficult to anticipate the ways in which the sw will need to be flexible |
Show |
| Reading badly written, badly designed or uncommented code.
In a professional environment, code should be written so it is clear the programmer cared about what was being done. |
Show |
| Every well-written software eventually "Peter principles" itself -- because it works, people keep adding to it until it becomes badly-written software. |
Show |
| Broken code |
Show |
| Setting up the development environment. |
Show |
| Debugging |
Show |
| Continuously retesting for regressions (i.e. prior bugs that come back out.) |
Show |
| Being stuck with hard to understand legacy code bases. |
Show |
| Testing and writing test plans. |
Show |
| Changing requirements |
Show |
| Testing |
Show |
| Uncertainty if I'm breaking things while debugging/developing new features. |
Show |
| The administration afterwards. |
Show |
| Of course when it fails to perform what it suppose to do.. :).. |
Show |
| Depending on third party software/firmware (compiler libraries, CubeMX from STM, Harmony from Microchip, etc.)... |
Show |
| - |
Show |
| Repeating work |
Show |
| the power of software provides an ease to expand your code with many paths and layers of functionality on top of each other. Keeping the overview and understanding how to improve your code becomes more complex. Supporting tools are not easy to find |
Show |
| Nothing. |
Show |
| tbd, I probably like documentation the least, |
Show |
| Reading other people's messy and undocumented code |
Show |
| Bad variable naming, lon comments within the code. The code naming and short functions should tell much about the code with minimum comments |
Show |
| Unexplained failures |
Show |
| Sometimes is difficult to estimate the tasks and activities, specially when dealing with debugging. This can translate into frustration and extra time. |
Show |
| Can be exasperating |
Show |
| Deadlines, estimates, Agile. Poorly documented code, processes, tools, tests. Buggy tools that slow development. Lacking tools / debug features that would ease debug/test of code. Overbearing static analysis rules. Code coverage for its own sake. |
Show |
| - Undocumented and poorly commented legacy code
- Tools that don't work as supposed to out of the box
- poorly named anything (files/folders/variables/tools)
- Powershell (AKA PowerSh**t) |
Show |
| - Undocumented and poorly commented legacy code
- Tools that don't work as supposed to out of the box
- poorly named anything (files/folders/variables/tools)
- Powershell (AKA PowerSh**t) |
Show |
| fighting the tools |
Show |
| Lack of clearly defined requirements. |
Show |
| Sometimes it may be difficult to get information on parts of code outside of your project. (Blockers rather), In addition, sometimes the build system generates erroneous warnings/errors. |
Show |
| It can get a bit frustrating when it takes a long time in finding the root cause of a problem. |
Show |
| It's easy to miss out on the bigger picture of the project when looking to much into the detail. |
Show |
| Not enough time - no time to experiment, innovate. Not enough inclusion in the path forward. |
Show |
| debugging |
Show |
| Spending hours looking for a problem in the wrong place because my initial assumptions about what to look for were wrong. |
Show |
| Determining what a customer really needs vs what they think they want.
Arguing with management about priorities, especially around tooling, refactoring etc. |
Show |
| Intentionally left blank. |
Show |
| The dauntingness that I sometimes feel around trying to wedge something in to legacy code. |
Show |
| Painting yourself into a corner w/bad design decisions. |
Show |
| Software can be used to multiply the stupidity of the human brain. |
Show |
|
overhead. |
Show |
| Documentation
Some documentation provides value for developers (both now, and in future) but other documentation exists only to meet a process checkbox |
Show |
| Stuff |
Show |
| Documentation, mindless writing of functions based on requirements without visibility of its end-user purpose or opportunity for creative input |
Show |
| testing. |
Show |
| n/a |
Show |
| Having to work with poorly documented APIs and tools. |
Show |
| The process. |
Show |
| The most difficult part of developing software is that we are not usually allocated enough time to develop it. |
Show |
| creative activity |
Show |
| Unreasonable schedules. |
Show |
| The ever changing landscape, very difficult to keep up. |
Show |
| Bureaucratic bean-counters who apply metrics without understanding. |
Show |
| How easy it is to get something wrong. Difficult to re-use code |
Show |
| Bureaucracy. People who don't know what they're doing messing things up for the rest of us. Can be a grindstone sometimes |
Show |
| Waiting for ... build, test, reviews, approval to ship |
Show |
| Frustrating bugs that take a long time to track down. |
Show |
| Nothing comes to mind. |
Show |
| Finding out that my solution isn't what the user needs/wants, fighting with development tools, repetitive boilerplate tasks. |
Show |
| Unclear requirements.
Legacy spaghetti code (followed by un-peeling the onion).
|
Show |
| none |
Show |
| I don't like how long it takes to push code into the repo, depends on reviews |
Show |
| The changing of names |
Show |
| Design complex, overlap... |
Show |
| Debugging |
Show |
| Testing |
Show |
| Sometimes I feel that we have to spend a lot of time to dev features which actually is not helpful |
Show |
| Doing firmware development mostly in C, sometimes it takes more code than other languages to do the same thing. |
Show |
| Sometimes it affected to my life |
Show |
| When the system is too complicated then bug is easily happen and hard to find |
Show |
| Not sure. |
Show |
| Debug and fix issue of another developer. |
Show |
| Nope. |
Show |
| Software Bug. |
Show |
| complecate |
Show |
| nothing |
Show |
| The endless number of ways you can build something. |
Show |
| Battling rapidly changing stacks when supporting a long term product. |
Show |
| Reinventing the wheel.
|
Show |
| Working on poorly documented/commented software written by someone no longer at the company. |
Show |
| I do occasionally get frustrated with poorly documented and unreliable code. |
Show |
| trying to decide requirements up front |
Show |
| N/A |
Show |
| na |
Show |
| Chasing bugs that can't be reproduced. Fixing a bug only to discover that I've broken something else that seemed entirely unrelated. |
Show |
| Too many opinions on how code should look, what functions/variables should be called and the 'proper' formatting. |
Show |
| Generally people outside of development group (management?) underestimate how much it takes to develop software. |
Show |
| fighting tool chain issues |
Show |
| Cutting corners to "save time" to meet an arbitrary schedule. |
Show |
| A reasearch & development is a long and tedious process in which a very high value is sometimes assigned to a a very small goal which after achieving turns out to be very small thing in the whole picture. |
Show |
| getting test harnesses made |
Show |
| can be monotonous |
Show |
| Would like more exercise. |
Show |
| Debugging |
Show |
| Bug fixing.
Bug fixing.
Bug fixing.
....
Oh, and bug fixing. |
Show |
| Many teams are disorganized and mismanaged, with the developers working in radically different ways. |
Show |
| Flexibility is a double edged sword. It is easy to do quick modifications to make a software design do something it was not intended to, introducing unintended consequences. |
Show |
| The parts of development that are not programming
- Managing releases
- Sprint planning
- Parsing external requirements |
Show |
| It often takes longer than you think it should |
Show |
| Unclear requirements. Focus on (narrow) features rather than quality/efficiency/ maintainability of code, working to deadlines. |
Show |
| software Bugs :)
Unclear requirements, changing priorities |
Show |
| When the framework becomes unorganised |
Show |
| - |
Show |
| The testing part gets tedious - but then it is essential! |
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