Had an interesting conversation with a good PM recently (yes, there are such things as good PMs).
There was a project that revolved around upgrading an application from a much earlier version of the .NET framework to a more current one. Even after the upgrade, the overall workflow process includes a number of manual steps in error scenarios that are sub-optimal. A developer on a different team suggested that it was a mistake to allow such manual steps. Surely, proper usage of the capabilities of the .NET framework could eliminate these manual steps.
From the outside, this suggestion seems correct. However, what the developer in question didn’t know or recognize is that the scope of the upgrade did not include eliminating these manual steps, and so wasn’t budgeted for (rightly or wrongly).
When discussing this with the PM, I pointed out that the developer wasn’t considering things like budget or scope. The PM suggested that this was the norm. Even good developers don’t consider these things.
Though I get his point, this took me a bit by surprise. Almost all of the best developers I’ve ever worked with do consider these things, yet he was insistent that in his experience, this isn’t the case.
It seems to me that any developer that wants to consider themselves to be a good developer needs to take these into account. Although this is especially true when dealing with more traditional corporate environments, it also should be true in start-up situations. All development efforts are constrained by time, quality and cost.