5

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.

2 Answers 2

4

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.

2
  • Your answer neglects the commercial reality that in many markets there is a strong preference for fixed price contracts, and clients will simply not offer a contract to a contractor who won't commit to a fixed price.
    – Jules
    Aug 25, 2015 at 15:16
  • @Jules: let's talk about the commercial reality. The preference is for low price. By carefully choosing programmers who commit to a low and fixed price, they end up receiving software products that nobody wants: unusable, full of bugs, late. Smart customers start noticing the trend, and turn themselves towards professionals, who don't commit to a fixed price if they cannot, and don't lower their prices by lowering quality. Other customers continue failing, again and again. Who do you want to work for? The smart ones, or the ones who are unable to understand software development industry? Aug 25, 2015 at 15:22
-1

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.

2
  • 1
    Its too easy to say "that;'s a solved problem, your complex system should not be complex" when a) you don't know what the requirements actually were (they might be very complex - I worked on government IT systems and they have ... interesting requirements that have to be fulfilled, not matter how stupid) and b) the requirements may not be involved in the auth of the user, but what happens after that.
    – gbjbaanb
    Aug 25, 2015 at 14:48
  • @gbjbaanb Thanks for the feedback - I see what you're getting at, but you're getting hung up on Auth as an illustrative point. Code still reinvented the wheel; sometimes clients demand you reinvent the wheel but the warning is there to tread carefully or it will bite you. Ultimately the problem as presented was a design issue and not repeating it means learning to recognising the warnings at the design stage that were missed in this case. Aug 26, 2015 at 16:21

Your Answer

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

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