What document/artifact should alert me when an old requirement changes the scope of new one?

Question

I developed a software application a year ago, I delivered it with a simple documentation.

For example, it has an special and complicated login system as requirement.

Now the customer calls and ask me to change the application for support a new kind of users, then I review (quickly) the tables, views and code that I need to change to deliver the new requirement support a new kind of users and give an estimate time, but I forgot completely that I need to refactor the special and complicated login system.

This is a big mistake because the time that I will spend in the refactor of the special and complicated login system will not be paid.

What errors have I made? and how can I avoid it in the future? A trace ability matrix gives me relations between test cases and requirements, but I need the track of old requirements in relation with new ones.

Answer 1

Contract matters

This is a big mistake because the time that I will spend [...] will not be paid

Actually, the big mistake is that your contract makes it possible that you spend your time working for free. It doesn't matter if you are solving a bug or learning a technology required for a new project: the customer has to pay for the time you spend.

You should not work for free. That's as simple as that. It makes you feel bad, and it encourages your customer to think about you as a guy who works for free anyway, and so who don't have to be particularly respected, or paid at all, after all. As soon as your customer knows that you spend one hour working for free, your relation is screwed.

This is also why it is essential to have a contract written by an actual lawyer specialized in software development contracts.

Technical estimates

What errors I did, and how can I avoid it in the future.

Technically speaking, you error was to give an estimate too quickly. You may have spent maybe a few more hours studying the impact, and probably find the relation between the data and the authentication.

But such mistakes happen anyway, so it's not a big fault from the technical point of view.

This is not very different from cases where you give an estimate of two weeks for a task, and a week after you started the task, you find that it requires much more work. Then, you simply send to the stakeholders (would it be your manager or your customer) the readjusted estimate which takes in account the things you have discovered meanwhile.

You may have made a mistake of giving a very precise estimate. If you tell that a change will take “eighty hours”, this is not the same thing as “ten days”, and not the same thing as “two weeks”. Moreover, estimates are often represented as a range or contain a hint about the precision:

The task will take from 4 to 9 days.

or:

The task will take 16 days ± 4 days.

This makes the progressive readjustment of the estimate more intuitive.

Another important aspect is that you should be able to say no. This applies specifically to those two types of questions:

“Do you know how long this task will take?”

If you don't know how long the task will take, don't tell “Three weeks” just to get rid of the person.

“Can you make an effort to deliver it faster?”

If you answer “Yes”, it means either that your last estimate was wrong (in which case, why would you make wrong estimates in the first place?), or that you know how to be more productive, but don't do it unless specifically asked, which doesn't sound very professional either.

It's all about leverage

But, again, the most important thing is how do you interact with your customer, which boils down to two things: what contract says and what is your leverage.

For instance, compare this message:

On February 7th, I sent you an estimate of 8 days ± 3 days for the task of migrating the bottom menu to the new data source. It appears that the task also requires to make changes in the top menu, since both partially rely on the same code. Given those new elements, the updated estimate is 11 days ± 2 days.

with this one:

On February 7th, I sent you an estimate of 8 days ± 3 days for the task of migrating the bottom menu to the new data source. It appears that the task is much more difficult than I thought, so I'm not sure I'll be able to release the changes on time. Can you, please, accord me three additional days for this task?

The second one sucks. It shows that the developer has no leverage whatsoever. It doesn't give any estimate, but barely begging for extra time. It feels like the developer screwed the original estimate, and feels bad about it. The first message is purely informal: here's an estimate, I don't care what you think about it and I don't need your approval, since our contract doesn't require your approval in this case. My early estimate was correct, and the later one just takes in account additional info. Nothing more.

Answer 2

This is a big mistake because the time that I will spend in the refactor of the special and complicated login system will not be paid.

There is a big red flag showing you what has gone wrong. The problem was embedded in this project before any changes were requested by the client, they were there before the code was even written...

Authentication and permissions are very well-known (and solved) problems even for exceptionally complex sets of requirements (2-factor authentication, time-locking, location restrictions for example).

The next step is to prevent recurrences...

You can reflect on the original development process and examine your design documents/process to understand the factors which led to those components being tightly-coupled and warning signs to look for. Generally, when a common function is considered 'special' it's a good indication that the situation hasn't been fully understood for example.

Instead of taking this situation as a 'cost', take it as a wake-up call that you or whoever worked on the project might benefit from some professional development to better understand the development process - it's something good developers do all the time and using that knowledge to make sure that future projects are more amenable to extension and that code is easier to test/fix. It has given you a chance to produce better code in the future.

As starting points the Single Responsibility Principle (SRP) and Separation of Concerns (SoC) should have kept unrelated code apart and mean that you shouldn't need complicated matrices of dependencies in the future.

Grab a couple of books on code quality and spend some time on them, it will not be wasted, and a few days of extra dev time is cheap compared to some projects that lose months due to issues that could have been avoided.