Our development team is currently facing the problem that the complexity of our software project is draining their motivation/enthusiasm/... Since a few weeks they constantly struggle with pondering over problems for days, making little to no progress. As a result they began questioning their skills and lost motivation.

Our goal now is to improve their motivation and perhaps skills, as well as ensuring project progress... Does anybody have good advice on this matter? Perhaps a good book on conquering complexity?

A bit of background-info: The team consists of five developers including two senior developers. The workplace and working conditions are formidable.

  • 3
    What do you mean by formidable?
    – Nathan
    Commented Feb 12, 2017 at 1:17
  • Decompose work using the INVEST mnemonic.
    – Todd A. Jacobs
    Commented Feb 12, 2017 at 17:26

4 Answers 4


the complexity of our software project is draining their motivation/enthusiasm/...

That's mostly bullshit. Technical problems very rarely drain motivation. There are many sources of draining motivation, the biggest of them being bad managers (both administrative and project-).

It does not matter what solution you will apply, it will most likely fail if you do not find the root cause. And you can find the root cause ONLY by talking to the developers.

Note: please be aware that YOU yourself might be the source of draining the motivation. If that is the case, you will be quite alone in this task, to restore the team, since you will have to change yourself.

they began questioning their skills and lost motivation

I really doubt it. It is a lot more likely that their managers are "reminding" the developers how "incompetent" they are for not being able to do "such a simple job".

And when the said managers attempt to be motivational, they will drop the famous "I trust you to do a wonderful job". Placing all the burden of responsibility on the shoulders of the developers.

I will try not to bring into discussion the other famous motivational statement: "you are experienced developers. We have high expectations from you".

Just curious: what is your exact relation to the team and to the project? You surely do not identify yourself as part of the team - in any sense of the word. You are you and they are they. Maybe that is the starting point for the analysis you need to make.


Developers like to make software which solves the business problem in an elegant and generic way, such that new requirements can fit nicely into a greater system.

Solving that problem, of adjusting an existing system to incorporate a new requirement in a way which makes sense within the system as a whole is what makes 'good' software and gives the satisfaction of a job well done.

However, this will often take longer than simply 'hacking' in the functionality, "if special case then do this thing" so there is always a pressure from the business to take these shortcuts.

BUT! If you keep on taking these shortcuts eventually the generic system behind your software is eclipsed by the hacks and special cases. At this point it becomes increasingly difficult to make a 'good' change.

You are then forced to add more and more hacks until the requirements of the software are lost in time. No-one can really say what it is supposed to do in any given case because of the layers on layers of special cases and modifiers.

When a system reaches this point it is "too complicated". You can no longer get back to the 'good' path because in doing so you would be forced to modify existing functionality. Developers have no choice but to add changes which they know are as likely to cause bugs and know they they are doomed to work on this software, never achieving job satisfaction and having new developers slag off how awful it is.

My advice to developers in this position is to change jobs. My advice to business in this position is to start a 'rewrite it all from scratch' project. This project will be a big money sink. and your original software plus large teams of admin staff doing things manually will continue to roll on making money.

But you MUST do the rewrite. Not to keep your bored developers, but because your new competitor is currently doing this exact thing. Copying your business model with a new sleek piece of software using all the latest stuff and unencumbered by your technical debt.

  • Thank you for you answer! The things you describe are correct- the funny thing is, that we just began a complete rewrite two months ago (paired with some changes in the team) ;-) Before this rewrite we had the problems you described. Since the rewrite we no longer do any 'hacking'- so the problem you described is no longer the reason. Our problem really is the complexity of the underlying field (medical) and the scope of the software. Commented Feb 13, 2017 at 9:28
  • interesting. I had to kinda guess which way to go tbh. The complexity of the actual problem though shouldn't really affect your devs.. Have you written the requirements of the software in enough detail or are you expecting the devs to invent something?
    – Ewan
    Commented Feb 13, 2017 at 9:32
  • 1
    Where do the devs get the requirements from? Maybe the requirements writers (BA, PO, whoever) are not doing a good job?
    – jhyot
    Commented Feb 13, 2017 at 11:11
  • If the software was not a monolith, an incremental rewrite would be worth looking into. However an incremental rewrite needs more inter-operability planning/design.
    – blispr
    Commented Feb 13, 2017 at 17:40

First up, the fact that you are here, asking this question, is already a large step in the right direction. Few things kill morale more than workers feeling that management does not care about their problems. The fact that you have a mindset geared towards improvement is very important.

Now, I agreed with everything Ewan said, up until the suggestion to rewrite everything.

What you need, with a problem of excessive complexity, is a solution of sufficient power and structure. This includes both the project management side of things and programming.

For the Project Management side of things, this involves several things: Requirements gathering and refinement. Not wasting too much time in unending meetings. Documenting all work done (ideally in a way linked to the source code) so the Team can look back and discover why a piece if code does what it does. Breaking work down sufficiently so that, rather than being overwhelmed by a gigantic piece of work, any given developer has only a single, do-able task on his/her plate (no multi-tasking). Etc.

For the programming side of things, you'll need a system that allows the code to be maintained as easily as possible. I'd suggest looking into Domain-driven design. Take note, however, that any architectural changes need not happen all at once via a wholesale rewrite. If your team implements a policy such that, whenever a developer touches the code, s/he leaves it cleaner and more structures than s/he found it, then you'll be fine.

You don't need to dump all of these changes all at once, either; you can ease them in bit by bit. Provided you get buy-in from the team (implementing any change without buy-in will always reduce morale, which would be counter-productive), then over time, as your system for handling work becomes more robust, the work itself will become simpler, and morale will improve accordingly.

  • In other words, doing whatever you can to reduce the burden of maintenance whether through documentation or more process to break things down and ensure higher quality.
    – user27307
    Commented Feb 15, 2017 at 17:02
  • check out the OPs comment on my answer though
    – Ewan
    Commented Feb 15, 2017 at 19:05

I've also been working as a member of complex heterogeneous development project. Our team consists of 12 members.

You can make them like an XP approach. Make them as a pair, and work together to fix any code or debug issues instead of expecting to make them to show progress on a daily basis. Make the schedule flexible with buffer arrangements.


  1. Make them as a pair
  2. Ensure the schedule is flexible
  3. Not allow them to work more than 10 hours.
  4. Ensure they have a physical sport one day in a week.
  5. Earn their trust that the manager is always to support them
  6. Let one pair test and one pair develop , alternatively. Also ensures cross functional knowledge.
  • 3
    urg pair programming to improve moral? 10h work days? enforced sports?
    – Ewan
    Commented Feb 12, 2017 at 10:30
  • 1
    These are all good things for a team to do, but they have to come to it themselves. Forcing a team into these things will just make a demotivated team quit.
    – RubberDuck
    Commented Feb 12, 2017 at 12:25
  • Thank you for your answer! The pair programming aspect could help us in some situations- i will evaluate this aspect! Commented Feb 13, 2017 at 9:29
  • @Ewan it is working I believe
    – user27507
    Commented Feb 13, 2017 at 10:19
  • @RubberDuck juniors have never felt or openly said they are being forced. They said it's good to have change in routine work. Sorry if I had sounded like forced.
    – user27507
    Commented Feb 13, 2017 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.