August 7th, 2009
A friend of mine has been working on a proposal for a more competitive and, he argues, efficient workplace in the computer software industry. I won't go into the details of his proposal because it is his to expose (and exposé), but it did get me thinking about the challenges we in the computer software business do have to address and overcome—by and large we are overcoming them already as the industry matures, but it never hurts to understand the nature of the problems themselves.
In general
Think about an application that experiences overnight success (e.g., MySpace, Facebook, Twitter). It inevitably faces heightened complaints from users, the result of growing pains. How does this happen? Original code is often written as a "what if?" exercise that proves useful or fruitful. Right at that moment, a rewrite could be made so that code is properly organized ("architected"), internally documented, and optimized. Or, because you are the first to market, you ought to just get that software out there now while you have a competitive advantage, and worry about refactoring later. Except you never refactor—at first because it ain't broke, so why fix it? Then later because you are too busy, the code base has grown too big, and there is little internal "political" will. The chewing-gum-and-chicken-wire application is implemented first and sticks out of inertia. And you wouldn't want to advertise the fact you're refactoring code; it would make customers wonder what kind of crappy code they are running on right now.
There's not much of an organically-grown sense of team spirit in the software business. Teams tend to start in small operations, become cliques in moderate-to-large ones, then become an old boys' network at the corporate level. Also, bear in mind the fatal flaw in Leviathan, which should be required reading for anyone in the corporate world—even mailroom clerks and receptionists: It assumes people consistently act in their best interest. It minimizes or ignores nepotism, romantic relationships, self-destructiveness, and just plain stupidity.
Growth (pains) of an organisation
In tiny companies, sometimes developers participate in sales and support, sometimes sales assist in support, QA, managing resources, etc. These are not just multiple hats, but shared multiple hats. Everyone knows what's going on.
When a company starts growing, there is an informational bottleneck. But, contrary to popular belief, the specialized knowledge carried in developers' heads isn't the bottleneck. It is the sharing of the knowledge that is the critical path, and that path has many (often impassable) obstacles. Knowledge is like water: the more you contain it, the more valuable it becomes (and, like water, it has the potential to corrode its vessel). Also, veterans are sometimes threatened by newcomers. Maybe newcomers know new technologies, or the sharing of the specialized knowledge lowers veterans' stock in the company.
Team-work grows organically or not at all. Time and again the mistake is made by those techie pseudo-managers and by the managers out-of-touch with the reality of human nature to somehow legislate team spirit. They never understand it doesn't work that way: team spirit can be fostered and encouraged with positive reinforcement, but sending everyone to paintball or sitting in a circle talking about your favourite childhood hero isn't going to cut it.
Sometimes a company can't hire fast enough to keep up with its growth: A Product Manager may go to Development Managers with a feature list (must-haves, nice-to-haves) and the Development Managers inevitably come back with a list of their own: "Can-do" or "need more Devs", etc. Empire builders are always exploiting this process, and Product Managers often don't have the power to say no to Marketing, which means they have to help Development Managers to hire more staff; or Product Managers don't have the power to help hire staff, which means that they have to deliver a shortened feature set.
Documentation
This word means many things to many people. Marketers, Developers, Product Managers, Technical Writers ... all have different ideas about what constitutes "good documentation". All are potentially right or wrong, depending on the context.
Depending on how it is handled, poor external documentation helps temporarily boost support revenue or it boosts support costs in the long-term, instead. Organisations that value good external documentation are well-known: Oracle, Microsoft, SAP, IBM, HP, etc. Organisations that take a short-sighted "immediate value-added" approach to good external documentation are also abundant, but needn't be listed here, since you've likely never heard of them, or they have already gone bankrupt.
Internal documentation has different issues: some programmers find it painful to internally document code, occasionally because of language difficulties, almost always because of insufficient communication skills. Also, developers tend to feel internal documentation is a waste of time because bugs can be blamed on the platform (e.g., OS or run-time environment) or when assumptions are made by one third party that are mutually exclusive with assumptions made by another. Also, programmers sometimes automate repetitive coding tasks, or module creation. Automated scripts do not generate meaningful (if any) comments. Some developers with particularly poor interpersonal skills think "Why document it? You just have to read the code to understand what it does!"—someone at a former company once said this to me, then she suggested I look for a new career!
Conflict in larger organisations
Employees cannot take documents, artefacts, or code from their old workplace to their new workplace. This is almost universally accepted—indeed, it forms an important part of every employee's employment agreement. But at some point IP becomes just experience. Every time a Developer or QA Engineer, Technical Writer, or Support Analyst moves on he takes corporate knowledge and experience with him, and though the code or document might not be exactly the same, what he learned in the last job informs him in his next. Re-writing the same code in another place is not IP theft: For all intents and purposes, the difference in the storage media is his brain instead of a CD or DVD he burned before leaving.
Think of something like a service layer or base application that is used both internally, and sold externally—with high levels of BA and Support (and, presumably, sales engineering)? Right now, it is treated as a product and marketed, sold, etc. The existing problem comes when an external customer requires changes or modifications that the internal "customer" does not, or, worse, the internal "customer" needs new features that the external customer does not. Money drives the development, which means that the internal "customer" does not get traction with Product Manager for needed changes. Really, by repurposing an application both internally and externally, a company has created the potential for a conflict of interests inside its own organisation!
Confidence (or lack there-of) is affected by people who lack the ability to objectively assess their own abilities and the company's potential for profit. I know lots of people who were convinced a venture was going to be profitable and therefore worth their effort and time, only to discover they were living in a fool's paradise. I know lots of people convinced that doom was around every corner (a common human characteristic—maybe a survival instinct?) but nevertheless belonged to a rising success story. And there is assessment of one's own abilities, which can be both over- and under-estimations. The personality of the estimator is independent of the factual potential.
Read more rants - Comment on this rant - Email me