Lipstick on a pig

If you've ever seen one of my project plans, there's a chance you've seen a task at the end that says "Add pretty". With good use of stylesheets, you can radically improve -- or damage -- the look of a website even after all the coding and most of the testing are done. A different person or group with a different skill set can take over from the programmers and work some magic with little interaction.

You might think, based on this, that other parts of development can be pushed to the end after "real" development is done. You'll know someone was thinking that when you see a task late in a project plan that says "Add fast".

I suppose I can live with the idea that there will be some performance tuning that's best done once everything else is complete. And on some projects just throwing more hardware at the problem is cheaper than a programmer's time to fix it. But actually improving the performance of an application is hard, and the changes pervasive.

The second manifestation of specialized groups, one that always raises the brown flag, is when I see "Add security" at the end of a plan. It's simply inexperience that allows anyone to think they can graft a security model onto a codebase after the fact without significant amounts of rewriting.

"But this is a quick hack, and we only need the numbers for this one meeting." Sure, a report you'll only ever need once. I guess such a thing could exist, but I've never seen it. In the first place, nothing lasts as long as a temporary fix that works well enough. And in the second place, many (most?) large, successful products started out as small, successful products.

End/begin dependencies look really great on a Gantt chart. Activities that invite and incorporate feedback don't look so neat and clean. Treating security as something that can happen to a product after it's already done is no better than ... well, see the title of this post.