I also heard an undertone of fatalism, and frustration about how to communicate, and I'd heard that many times before. Particularly in Web Design as an art, modern software engineering practices have only begun to really take root and infiltrate as a professional practice. This is because only recently have Web Designers begun to recognize themselves as serious software professionals.
That is not to say, that they weren't serious before. Or that they weren't software developers. It is just that in their daily practice, their brains had yet (and to some extent have yet) to converge on a common cultural recognition that they are professionals with a professional discipline.
There are many reasons for this:
- personal immaturity - a person is "just not there" yet, and may not see the value in reinvesting effort in skill building
- "fire fighter" mentality - fire fighters don't have to be concerned about building structures, they just try to keep the flames at bay
- stress - people who feel under the gun have much less presence of mind for reflection, self-improvement, or process improvement
- management reactivity - this contributes to stress too and IMHO is the most important root cause in a small business environment
The young developer mentioned that the idea of version control prevalent in their office was to yell over a cubical wall and say "Hey, I'm going to edit FuBar.html, is anyone else editing it?". Yet this isn't even a rudimentary version control such as copying to snapshot folders or renaming .bak files - it is just a verbal form of a semaphore.
The reason for this immaturity of practice? Ostensibly, it is that they do not have the time to pick up a new practice and put it in place, while also getting the backlog worked on.
The root cause is reactivity in management. I do not mean "knee jerk" reactions, although that is a visible sign of reactivity. It may alternatively be that management is poorly trained and possibly even incompetent. By reactivity I mean any practice that undermines a continuous improvement process by constantly misaligning the goals and the actual values expressed to the team.
Lumped together, you might just simply say it is bad management. Other signs:
- the company does not allocate a sufficient amount of resources for continued professional skill building
- calculated risk taking is discouraged; the level of proof required to bring in new techniques or technologies is set higher than the level of proof required to keep the existing known poor practices and technologies with persistent defects
- supervisors are not actively contributing to work output, but are all mere overseers
- heavy emphasis on documentation in planning, with little reference or use of those documents by the team performing the work
- frequent use of the word "just," "only," or other hedging language that diminishes the cost/effort/time/importance/complexity/thinking required to move forward in a sensible direction
- "Continuous improvement" is a cliche used often, but with no practical path of allowing developers to start moving down any path that changes the toolchain or tactics.
Now, here's the thing: that developer is young and that developer is smart, so that developer has the power to effect change. Period. And that should be the End of Discussion.
But it isn't the end of the discussion. That developer is also inexperienced and is fearful or at least risk averse, and it is the employer who has the money. There is a real power imbalance when the developer sees herself as the one who needs the money more than anyone else needs her skills.
By postponing skill building, the developer puts herself in a position to be used reactively.
By foregoing process and technology improvement - and suppressing the adoption of modern software practices - the employer keeps the developer in a co-dependent posture.
The tactics the developer learns to deal with problems reactively are employer-specific, and thus much less non-transferrable. At best, they fail to make the developer more attractive to another potential employer. The employer can pay a co-dependent developer less, because the developer lacks confidence and lacks opportunities. Modern practices, on the other hand, make the developer more attractive to competitors and helps equalize the balance of power.
You get the idea. The sad thing is, co-dependence hurts all parties in a relationship. The employer will fall behind competitors, and so will the employee.