What kind of constructive criticism would help a development team?

Question

It is a good idea to give feedback to a software development team. What are you most dissatisfied/annoyed with in your development team?

The topic could be anything. For example:

• roles
• attitudes
• the design
• the architecture
• the technology
• the personality of the other programmers
• the customers
• the office environment
• etc.

Do you think it would increase the productivity of your team if you gave such criticism?

My pick:

I hate it when people walk pass by my desk and talk about my screen ...

After answering here, you may want to provide your generous feedback to your team which can then be used as a reference by the developers and team lead.

Answer 1

People eating (smacking) loudly in the cubicle next to me.

Answer 2

The fact that "The Mythical Man-Month" is still true 20 years later... and those "Management Gurus" haven't got any solution to the problem of managing technical people yet.

Answer 3

People who spend all their work time browsing Stack Overflow. ;)

Answer 4

Team mates that try and stick their nose in everything that doesn't involve them. It wastes other people's time, and their time. Everyone doesn't need to be involved in everything. Isn't that the point of being part of a team? You trust what others are doing?

Answer 5

No requirements on paper.

Answer 6

Not having a documented and critically examined development process that we use as a development team.

Answer 7

Here's one piece of feedback that I've shared with almost every development team I've worked with: you are not the customer!

In other words, people who build software are typically much more sophisticated than users of that software. Development teams need to take that into account and build for users' less-sophisticated needs, instead of their own more-sophisticated needs.

Some examples:

• features that developers might like to use themselves will often be too complicated for most real users
• developers often underestimate the importance of "un-sexy" things like "Getting Started" documentation, clear error messages, and other parts of software which are not much fun to build but which are key to user adoption.
• development teams (and marketing teams!) often overestimate the number of features that most users will use, and therefore prioritize completing many features over making a few features really, realy easy to use.
• teams often underestimate how much time it takes, once core functionality is complete, to get the level of usability, ease of use, and UI fit and finish necessary to appeal to relatively unsophisticated users. In other words, a command-line interface may not be good enough. :-)

The best solution I've found to help a development team understand end-users' need for simplicity and ease-of-use is to get developers talking with real customers or watching those real users interact (e.g. in usability testing, in video capture, etc.) with the software they build. The closer developers are to the user, the easier it is for them to remember how different real users are!

Answer 8

The pain points that we still have in our process involving transitioning from one environment to another. After a year of doing a project we still end up spending a day moving things around which is taking 10% of our sprint time to do this move of simply taking what is in our development environment and move it into the test environment. We have tried a variety of different ways to try to make this easier but without success.

I suppose the downside of this is that it is merely venting the problem rather than giving a solution to the problem other than just accepting that we will have these moments of pain. I temporarily choose to accept it but it definitely is in the land of my chief annoyance where I work.