How to keep your productivity level high when people keep changing requirements at the last minute?

Question

I started working as a software engineer with a startup about one and a half year ago. Everyone here cares about this project and works hard. but I have been having an issue here for some time.

People here have "lack of discipline" when it comes to development tasks. They ask for one functionality, I ask a thousand questions so that I am clear on the requirements of the functionality. As I don't ever like to miss a single scenario when collecting requirements. and I do my work with all my heart and brain in it.

Later on the day of the demo, they would say: let's change this to that and that to this. 5 demos later, trying to fit in their changed requirements and flow, I end up with a mess of code that works the way they want.

Now, because the flow is totally changed, it's not even the same function that I started with, there's delay in launch, there are bugs in production and marketing people are screaming about it. I always end up in some mess. and I am tired of it.

I can't fix the issue with these people, I can only try to fix myself, I believe that issues come when they make me work on the same thing again and again and I get demotivated to work and I procrastinate.

I like this project, I really want to stay here for a bit longer and I want to give my best even if I am working on something for the 5th time.

Any advice on keeping the productivity level high in these scenarios? How do I make sure that I don't miss anything while changing the functions? and what do I do when I feel stuck.

p.s. ATM I am making changes in the flow of a user portal that I actually finished flawlessly last week. and now I am stuck, I don't feel like doing it. and I can't even think how to fix these issues.

Answer 1

The idea that requirements are fixed and that the code you are writing will not have to be changed is extremely problematic. In reality, requirements are never fixed. Whether you need to change it prior to the initial release or not, at some point in the future, your code is very likely going to need to change. When that ceases to be true, it's because the code base is abandoned.

In your situation, you've identified that 1. your initial requirements are not what you will eventually deliver and 2. that you can't affect any change to that reality.

All of this points to one thing: you need to optimize your development strategy around the ability to change. A lot of software practices you will read about here are either about the ability to understand code later, the ease of modification, or both.

The first thing I would suggest is that you stop attempting to build a fully complete polished system before showing it to your product owners. Instead build functioning prototypes and get them in front of the decision makers early. Take their feedback, implement them and make things a little more finished. Show it to them again. Rinse and repeat. Eventually, you should get to a point where they start saying everything is OK except for the details. That's when you start finishing things off.

The other thing that stands out is that when you are making these changes, you are hacking them in. You should be following the same standards for your code whether it's a last minute change or if your code isn't due for 6 weeks. Yes, it's inevitable that you might need to tweak something at the last minute and clean it up later every once in a while but doing this as part of your regular release is very damaging to the code base. The more poorly written code you put in, the harder it will be to adapt to the stream of changes. Getting it in front of people early will help with this since you will have more time to make the changes appropriately.

The last thing I will recommend is a couple of specific development practices that can be very help in this kind of situation:

1. Modular code: If nothing else, make sure you are breaking code down into short readable methods with a single responsibility and meaningful name.
2. Unit tests: What's often misunderstood about unit tests is that they have relatively little value in determining whether your code meets requirements. Where they shine is when you are modifying code. They give an instant feedback when you have broken something. Keep them up to date and modify the tests that you need to change first before implementing the change.

Answer 2

JimmyJames answer covers many of the aspects well. I just wanted to add a few more points:

Reduce development time

Make sure you're writing as little code as possible. In particular, you want to make sure you only have to change code in one place (DRY) and aren't adding bells and whistles too early (YAGNI).

If you find you are making changes to the same code over and over and the structure is suffering, then by all means refactor to stop the software entropying further.

Increase accountability

Ensure all changes are documented. You'd be amazed how many requirements disappear when there is a paper trail!

Make sure all changes are verifiable. Wishes such as "that should look snazzier" and "that form could do with tidying up" are time drains. Ensure changes can be proved.

Finally, if development is time boxed to say, a sprint then there will be less temptation for endless tinkering.

---

As a final takeaway, making peace with the fact that software often changes (for many reasons) will stand you in good stead going forwards.

Answer 3

Reading your story, one thing stands out for me. Your attitude is very reactive/responsive/following. You expect your stakeholders to have a vision and give you smart, future proof tasks. The problem of course is they are not that smart or foreseeing. They just have some wild ideas and they only find out what is wrong with those ideas when you show them what they asked for.

So instead of pinning them down on what they asked for and mindlessly producing that, you should iteratively brainstorm with them until you all get a picture of what you want to be aiming for. Then you can take the first step to that (far) goal.

Your (and I mean "your" in a plural sense) frame is far too small now. You obviously want to go far but you do not know in what direction yet. Think a little bigger. Rather than taking an impulsive step into a random direction, try to think at least a couple of steps ahead and make sure you know where you (ideally) want to end up. Helping your stakeholders develop a vision can make your life easier and your job more rewarding.

Answer 4

Realise that you are not being paid to create 'good' software.

You are being paid to complete feature requests as fast as possible with zero defects.

This is achievable, you can be good at doing this and take pride in it. The business accepts technical debt.

• Write loads of tests so you can be sure of the zero defects.
• Get sign off on specs and change requests so you don't get blamed for writing the wrong thing.
• Get your CI process in place so you don't have to do any infrastructure/deployment tasks.