Back in my PHP developer days, I was asked once to implement a PDF exporter for reports inside our application. Since we had time, I was given some to research and make the decision on what resources I’d use to achieve it. After reading some documentation, I concluded that Zend PDF suited my needs and I informed my manager of that. He gave me the OK and so I moved on with the actual implementation.
It took little more than one day to realize the hole I had dug for myself (the reasons for this fall out of the scope of this post, so I will abstain from stating them). I spent over one week complaining loudly at every single little issue I’d come across with, I was pretty sure that other solutions would serve us best, at the time and future!
My manager told me something then, making it crystal clear “You were the one that made the choice, live with it”. As harsh or frustrating that may have been back in the day, I realize how critical it is to follow this rule. Don’t get it wrong, people do make wrong decisions and be tempting to take a turn from the plan at some point, a plan needs follow up and sometimes adjustments so that goals are reached in the end. What is unfeasible, specially if you are running on a tight schedule, is to totally change focus over the course of a milestone.
So you made a mistake, you “knew” that new library would solve all your problems and seemed perfect back when you first decide to integrate it. Turns out it did not, for a number of reasons, it does not cover all your needs, it’s unstable or even the underlying technology had some bad aspects you didn’t remember back when you started. Live with it. If you think you have the time to change, you haven’t!
Whatever the problems that you may have now, at least you’ve been working with them and you know what to expect. Making a big change at this point, for as promising as it can be, will add another unknown time consuming unknown variable into your now, “unplanned” project. Fact is, not only you just threw precious work hours out the window, you also don’t really know what to expect from this new path you are taking. Sure it seems great now, but wait, why didn’t we decided on this one in the beginning then? Also, what will you do when you face problems with this new one? Change back to the old? Maybe try a third, amazingly even more brilliant than this second one? Will you ever deliver anything?
OK, so you still feel like you have to do this, fine, at least set up a short deadline, one day, two, and work on a fully working proof of concept. That should at least give you an idea of what difficulties to expect. If you can’t fully achieve this by the deadline, it’s probably a indicator that you should forget this all together and get back to work ASAP!
In the end, there is no such thing as a perfect project, chasing it will lead you to nothing but postponed deliveries, missed goals, frustration and disappointment. But hey, good luck still!
I think the lesson learned to stick with the plan is great, however, the goal was to generate a PDF, the means to reach the end could change to accommodate the current situation. If the current solution will be a hassle for the current time and the future, then I don’t think it’s a good solution to stick with it (again, I agree with the concept in general). This is not a change request (see more on controlling change requests) and, as such, it shouldn’t be treated as one, this is merely a technical decision affecting only part of the project to achieve exactly the same thing but in a better way.
Hi and thanks for the response and sure, the example stated here is more a technical one, that shouldn’t affect the final features delivered, but there may be exceptions, such as affecting the supported platforms.
I understand that this is a “sensitive” topic and some flexibility should exist to the rule, sometimes there is huge benefits in making a mid-milestone change of course. Yet, this carries some risk due to the reasons I stated, so I believe that a working POC is a good idea before actually moving in with all efforts.