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
|