3

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.

1

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. – Rudolf Olah Feb 15 '17 at 17:02
  • check out the OPs comment on my answer though – Ewan Feb 15 '17 at 19:05
0

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. – Philipp Kanaan Feb 13 '17 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 Feb 13 '17 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 Feb 13 '17 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 Feb 13 '17 at 17:40
-2

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.

Takeaways:

  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 Feb 12 '17 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 Feb 12 '17 at 12:25
  • Thank you for your answer! The pair programming aspect could help us in some situations- i will evaluate this aspect! – Philipp Kanaan Feb 13 '17 at 9:29
  • @Ewan it is working I believe – user27507 Feb 13 '17 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 Feb 13 '17 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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