This is the second of a two-part post; to read Part 1 in this series, click here.
Last week, we discussed some of the problems inherent in working with developer tools, looking specifically at the obvious and not-so-obvious costs involved in purchasing new tools. Today, we will talk more about working with the tools you already have.
This flies in the face of the saying, “When all you have is a hammer, everything looks like a nail,” doesn’t it? The point is to use the right tool for the job. It sounds like I am advocating force-fitting the requirements of a project to the tools you have on hand. And that just CANNOT be right. Right?
Let me answer this by way of example. Say you are a developer in a small shop with a limited budget. Your department purchased a web portal a few years ago to create both corporate intranet websites as well as public facing websites. You have an established code base running on the portal. For the current project, there is a ton of CSS that you will need to customize. You desperately wish that the vendor used SASS, but they did not.
Do you suggest an entirely new portal platform that supports SASS, incurring a cost premium (that you diligently quantified)? Let’s put it another way – do you really want to develop and support two portal environments simultaneously? This assumes, of course, that you have the budget to buy and maintain another tool. Which in this scenario, you do not.
So, maybe you make direct changes to the CSS. And maybe you cringe every time the vendor updates the portal. You will have to do diffs between all the CSS files, manually reapply all your changes, and test every last site to make sure it works. Or maybe you lag behind on the upgrade cycle, especially if you can limit browser support in a corporate intranet. As an aside, this might also be a good time to take a long hard look at how much CSS customization you really need.
At some point, the cost/benefit may indeed suggest that you move to your new portal. But what do you do in the meantime? Argue about it to death in meetings? Or do you grudgingly do the inefficient (but effective) thing and change the vendor’s CSS files directly? One way gets the project done. The other does not.
Time goes by, and the department head notices the intense rework required to stay current in your existing web portal. Your quantified cost/benefit analysis is the centerpiece of the most recent development meeting, and a migration plan is drawn up to move to your new portal.
Months pass. Some of the old sites are migrated. Others are mothballed. The old portal is eventually retired. Someone brings in cake. The new-web-portal smell fades. Then one day, the department manager comes into your office and closes the door, and asks why you spent a lot of hours reapplying CSS changes once the new portal was updated to the latest version.
Maybe it was because you were too busy putting out fires to learn the ins and outs of the new product. Maybe it was because you secretly resisted the very change you advocated for any one of a thousand reasons. In the end, you kept updating the CSS files directly, failing to benefit from the features that the new portal gave you right out of the box.
In addition, you kept manipulating all of the CSS properties you were used to changing: same font faces and sizes, same button heights, and same browser hacks. Never mind that the new portal’s CSS templates were already responsive. Did you really want to mess with the layout when the vendor’s designers and developers spent months making sure it was just right? Do you really need that custom corporate typeface on that submit button?
As I was writing this article, I was thinking about prior projects – both mine and those of people I know. I have made each of these mistakes somewhere over the course of my career. Listening to my friends and co-workers told me that they made these mistakes, too. It can be hard not to go to extremes, clinging desperately to an idealized vision of what software development should be or resigning to projects presumably doomed to failure.
Finding middle ground – where you work with what you have to get things done – is never easy. Being aware of the tools you have at your disposal, assessing what you really need, and determining what improvements are worth the investment are not easy skills to develop. But the more proficient you become at using your toolsets effectively, the fewer headaches you and your teammates will have. And that is a benefit well worth the time invested.
Tech Talk Live is the only conference of its kind in the region specifically designed for IT pros in education.
1020 New Holland Avenue, Lancaster, PA 17601