"It would have been really cool to use module X because I could have used the same config for both things. Just didn't have enough time." Or "there just isn't any time to go back and redo some of it." Or "this thing is hacked together because we didn't have any time". And that is kind of hard to wrap my head around. Yes, time is always against us when the customer is yelling for feature X, complaining about bug Y and deadline Z is looming. They are writing the checks, after all. But, there has to be a point where something needs to be more "right" than "right now." I've worked on projects with some tight time lines. I've had to compromise on features, workaround bugs, and ship something I felt wasn't 100%, but I don't think I've kludged something together without ever revisiting it and correcting it.
As a programmer who takes pride in his work, it is hard to hear these kinds of things. Because to me, it sounds like the people making those statements are resigning to accept that the hackery and the shortcuts are worth more than the increase in maintenance time down road.
So how does all of this apply to Perl? Backticks. Network daemons that don't use POE. Manual parameter validation. Etc. All of the things that make Perl a swiss army chainsaw, also make it very easy to forget to engineer your software. That is why I like things like POE, Moose, Catalyst and others. Those modules help you to engineer your software. They discourage you from doing things like using backticks or reinventing wheels.
And using those tools to begin with decreases your development time. Those projects have solved a lot of the hard problems for you. They are forward thinking and keep their userbases in mind.
I wish I had a solid answer for people with the perpetual time problem.
Subscribe to:
Post Comments (Atom)
If only we always had the luxury of writing systems the right way from the start. I think more often than not, the important question is "how do we deal with the poor choices that some else made many years ago?".
ReplyDeleteI am not suggesting that it is ok to simply pass the buck. My question is, do the short-term/long-term trade-offs play out the same way when you are already in Maintence Mode?
I think the first step is Testing. Not only does comprehensive automated testing pay off in the long-term by allowing safer refactoring, it also pays off in the short-term by increasing quality in your existing code base.