is the Strategy Pattern (design pattern) less useful when the change is unforeseeable?

Question

Is the Strategy Pattern based largely on the fact that there will be change to the software?

1) So in today's environment, what if the change is total unknown and unforeseeable yet. At that point, will the Strategy Pattern be not appropriate to be added (at that moment)?

2) What if the Program Manager wants it done in 2 days, or ASAP or the faster you finish it, the better you look and the better the performance review. If you write it without using the Strategy Pattern, you may be able to finish within 2 days, otherwise, the PM may frown upon the delay and attribute it to bad performance. In that case, how do you balance the speed of implementation vs maintainability?

3) the same goes for programming under a contract job -- for 2 months or 3 months. Won't some programmer or the previous programmer on the job just ignore maintainability just so that it is done ASAP? Do the managers really care now that the project is 100% functional as spec'ed, whether it has the maintainability as well?

Answer 1

Well, sad to say, the project managers don't care about the maintainability. If you have the ability to move from job to job, hack out stuff quickly, get something more or less working (or at least looking like it's working), and head for your next job.

(This is pretty cynical, but unfortunately true. I apologise for not providing some suggestion of a solution to this, but that's more than I'm up to tonight.)

Answer 2

For 1), I recommend not to use Strategy Pattern. Overdesigning becomes very common these days, and provide little or negative impact to the maintainability itself. I have came across system which are designed to be easily extensible but in the end the extension never came to materialize.

Jeff Atwood have some suggestion on KISS and YAGNI.

Answer 3

Re 2) and 3), yes, you'll find plenty of unprofessional behavior at disfunctional companies, e.g. by project managers and contractors, but also by plenty of other so-called professionals (avoid such disfunctional companies, if you can).

Re 1), yes, in an agile development approach, where "refactor mercilessly" is the norm, and excellent tests empower such refactoring with assurance, the proper time to introduce a Strategy pattern is exactly the first time it's needed -- otherwise, YAGNI applies, and introducing the pattern prematurely would be an example of over-engineering.

Answer 4

You're speaking about different things.

First I think you should always keep YAGNI in mind so if there's is absolutely no hint that you are gonna need it, the your are probably not, so don't use it.

IF the change is known to happen but you don't really have a clue of the form it will take then trying to overdesign will be a handicap now. If it is possible to have it for your manager in two days but you waste 2 weeks trying to mold it into a strategy pattern then no wonder he is angry.

Only use patterns when you need them or you're reasonably sure you're gonna need them, if you aren't then don't, there'll be plenty of time to refactor, and keep in mind refactoring can be planned later on, when it's needed.

Another note. Using design patterns doesn't increase code maintenability per se. In fact, it can become an anti pattern. You can develop perfectly maintainable code without patterns because your code might not need patterns...

Finally... there's something that I always like to say about managers. Of course, some of them might be Dilbert's, but don't underestimate your manager. More often than you think your manager have more information than you do, so if he says it has to be done in two days... maybe there's a good reason for it. It doesn't help having a perfect, clean, maintainable code of a product you haven't been able to sell in a bankrupted company.

Answer 5

I think your worries are unfunded. In my opinion this is an easy pattern to refactor to. Write the algorithm the way it is specified at the moment, and try to isolate the possible change locations. Use common-sense OOD rules and add strategies later on should it be the case.