“There are very few true artists in computer programming, most are just house painters.” - Tim Bryce’s Law
Management consultant Tim Bryce doesn’t like programmers. Many programmers don’t like him either (here, here, here, here and probably in many other places).
Mr. Bryce’s view of programmers:
- programmers often bamboozle others and heighten their own self-importance
- the average programmer has a lower IQ than any other worker with a college degree
- programmers show signs of sloppiness and mental laziness
- they appear disorganized to make it difficult to judge how they are progressing on their work effort and reveal inadequacies in workmanship.
- the typical programmer often laments he/she is being overworked, underpaid, and unappreciated.
- to the programmer’s credit, they usually possess a curiosity about technological developments. However, this must be carefully nurtured by management - too much information may distract programmers from their job.
Responses on Mr. Bryce’s post (referenced above) provide many excellent points why Mr. Bryce is wrong. However, I want to comment points where he is probably right. Also I want to understand why some management consultants with more than 30 years of experience could have such view? Certainly, I reject Freudian view that an unknown programmer hurt feelings of Mr.Bryce in childhood (the main reason is that at this time the world had only few programmers and all of them are known).
Mr.Bryce’s target audience is not programmers (whose low IQ would probably prevent understanding his Theory P anyway), but IT managers and business decision makers. The underlying premise of Theory P is: “The more effectively we manage the people who program the computer, the better we can utilize the systems to support the information needs of the business”. This theory is not about live people, but about pragmatic business and lets consider the theory from this perspective. There are three points where Mr. Bryce could be partially right.
1. Programmers are not “Software Engineers”, but Translators.
I agree with this statement. Programmers indeed translate. However, I don’t agree with what they translate. Mr. Bryce writes that programmers translate “human understandable specifications into machine understandable instructions”. In reality, programmers translate fuzzy human needs and ideas, which are often far from not well-defined specifications. Sometimes the difference could be as between Picasso translating human feelings in art and house painter translating his customer orders into colored wall.
If the flow of ideas between customer and programmer is bad, translation will be bad, software will be bad and, therefore, programmers will look bad. And Mr. Bryce will be right (unless he starts using The System Thinking).
2. Many programmers are not “System Analysts”
Unfortunately, in many cases, it is true. Mr. Bryce writes: “A true “Systems Engineer/Analyst” studies business requirements, defines and develops business processes to implement the requirements, and specifies software requirements for programmers to implement. Regrettably, there are too few people performing this vital task and, consequently, the responsibility defaults to the programmer who is not necessarily equipped with the proper skills to perform the work”.
I do know many programmers who are not very good in understanding business requirements or don’t want to understand them at all. However, unlike Mr. Bryce, I believe that programmers must learn speaking business language, communicate directly with customers and understand their needs. I believe that true programmer’s job is not limited to writing instructions for computers. The professional programmers should become master translators of complex mental concepts into software.
Otherwise wrong interpretation of business concepts will make software bad and, therefore, programmers will look bad. And Mr. Bryce will be right again.
3. Programmers tend to fashionable, but not practical solutions
Mr. Bryce writes: “An elegant solution to the wrong problem solves nothing. It is important for programmers to learn to justify their technical recommendations from a business perspective.”
Indeed, many programmers are more interested in technical and even fashionable solutions without considering business perspective. Can this happen, because often technology is the only area where they can apply their intellect and creativity? Can this happen, because management doesn’t involved programmers in decisions related to business domain and understanding customer needs? Can this happen, because programmers are often disconnected from real business needs and goals of the projects?
Over-engineered solutions, which are done with fashionable technology, but without practical necessity are bad. However, if two prior points could become true - programmers work directly with customers, understand their needs and translate them into the software - programmers will not have time and desire for fancy technical solutions, but will strive for pragmatic, lean and focused on customer value solutions.
Theory P Corollaries
Mr. Bryce consider programmers as the herd of wild geeks who need strong management control. These management shepherds should control programmer’s lazy, pseudo-intellectual and capricious nature. And also software projects need the army of business analysts who can chew over for programmers business needs (as low IQ obviously doesn’t help programmers to get it directly). And certainly software projects badly need management consultants like Mr. Bryce who can tell how to properly treat programmers and create theories of their behavior.
There is another way. Treat and trust programmers as responsible human beings, let them work directly with customers and let them make most project decisions. It is not an easy shift in minds considering existing stereotypes from both management and programmers sides. But it could be done in The Ideal Software Company.