Hackers and the Beautiful System

On the heels of Steve’s wonderful post on the joys of being a creative programmer, we get an idiotic Infoworld post on why American programmers are so bad…because they are hackers?

I like to think that the Hacker Ethic (creative, open exploring of systems and solutions) helps to create beautiful systems, but Neil McAllister seems to think that hackers are actually “hacks” – kids with no coding skills or business knowledge that must be streaming out of our university system if he felt the need to write such a long piece on the subject. He got one thing right, most university students can’t code worth shit because coding is assumed to be the “dirty” job in a Six Sigma – like development process system. There are virtually no classes on proper coding in a university IT departments. The funny thing is, if you really examine it, the real dirty, boring work is in the process modeling, business requirements collection, and scoping of the system. Once taught, these “skills” can be applied almost rote with no creativity or real thinking necessary in their implementation. Before you go off calling me a “hacker”, who doesn’t understand the process, you should know that I am a trained System/Business Analyst. It’s just that I am also a highly creative developer. I am not allowed to use my development skills much at my day job, that’s why I have this blog. Business analysis skills are necessary skills and that’s why they are taught to every business school and IT graduate. They are, of course, drone skills. The real “SKILL” is not in these “SOFT” skills, but rather in the brilliance necessary to actually create a working, beautiful system from pages upon pages of documents and processes that are produced by the “soft skilled” legions. A “hacker” as Neil would wrongly describe as an inexperienced developer with neither code or analyst skills is NOT a Hacker.

I like to call people who allow a Six Sigma-like process to rule their development, “process nerds”. The process nerd has been supplanting the “computer nerd” in corporate I.T. departments for years now. One thing I have found out by experience is that even a well defined, well executed process will NOT create great or even good software without brilliant, beautiful, creative hackers behind the development wheel. By Hacker, I am referring to highly skilled developers and systems analysts that like to think outside the box and create beautiful, custom solutions. Remember though, most programmers are lazy, so even a highly skilled, creative hacker will re-use a code library if it makes his job easier. It is the thinking that goes into deciding to re-use or re-build and then the brilliant use of technology to satisfy those pesky business and system requirements that a Hacker uses to create a beautiful system.

Normally I peruse Neil McAllister’s blog every now and then on the Infoworld site. I like him, and he doesn’t bug me often, but this time he has pissed me off. The article assumes that “The Hacker Ethic” is about cowboy coding with no use of planning an process. The fact that he has hacker defined completely wrong aside, this is what these Six Sigma process obsessed idiots will never understand. THE PROCESS DOES NOT CREATE THE SYSYEM! The process makes the system easier to build, refines the business requirements, and hopefully uncovers the risks involved, but for the most part, the technical requirements, technical design, and development create the system. Neil, for some reason, thinks that American University programs are unleashing hoards of right-brained hacker sloths on the poor unsuspecting business world. In reality, he has it completely backward: University business schools (to their detriment) teach the Six Sigma process skills in abundance to their business students and nothing else. The students that opt for IT training will get a small level of code training, but mostly system analyst training (along Six Sigma lines). There is very little, if any, critical thinking, logic, applied design, technical architecture, or code standards taught to these business students. Those skills are taught in the dwindling CS/CE departments, where the engineering methods are used rather than the business process methods. The students in Six Sigma style business and IT programs have to learn to code on  their own. That is the problem, and Neil is right, but they don’t lack Business Analyst skills as he asserts, that’s ALL they have! Issue each student a copy of Code Complete, NOT From Good To Great and you might have a lethal combination – a business process nerd student that actually understands what it takes to create a beautiful system, now that would be a revelation!  What our technical students need is a foundation in proper coding and requirements definition, not in process and paperwork. A book like Code Complete, while a very technical tomb on software engineering best practices, also stresses technical requirements collection and technical design – NOT JUST Requirements Collection and Proper Planning, and not just a process to follow with no hard skills! It covers both sides of the equation. What we need are more well balanced developers with a swath necessary of skills, not legions of business process drones.

I see IT departments laying off “rock star” caliber engineers in favor of develop factory drones and MBA process nerds all the time. The process nerd’s job is to document the process, provide governance, and define business scope, and requirements. Process nerds call on the “development factory” or “shared services” (read outsourced) drones to estimate and and build the system. This is probably an OK solution for data warehouse reports, packaged software implementation, desktop upgrades, and even Microsoft Sharepoint sites, but it is SHIT for software development. Most IT departments are not about software development, they are cost centers and governance organizations tasked with supporting a multitude of various systems. So, for those types of systems, the Six Sigma style works pretty well. But, if you want to be better than that, you need highly skilled and creative technical people to deliver you systems that are not plain vanilla.

Don’t get me wrong, design docs (especially for games) and nicely defined requirements are NOT against the Hacker Ethic. Actually Hacker Ethic has absolutely NOTHING to do with requirements, rather it celebrates creativity, exploration, open systems and sharing.  I am all for well defined requirements, Business Process Modeling, Context Diagrams, and other Business Analyst related tools and documents. They are a piece of the puzzle that help create a working system, but mostly they are used for CYA – Cover Your Ass sign offs at pre-defined process Gates. The Six Sigma processes do work, but the dirty little gray area they always leave as a BLACK BOX is the “development” portion. They don’t understand what it takes to actually code a beautiful system. The process does NOT create the system.

Let’s be frank here. If applied to my favorite subject, Game Development (or any software product, even and internal Business Solution), which team would you choose?

(a) A team of 5 brilliant, creative engineers, who lack Six Sigma process skills, but understand how to create a great system.

or

(b) A team of 5 Six Sigma trained business analysts who provide 100’s of pages of documentation, sign offs, but have no real development skills.

Team (a) includes Code Complete trained hackers with beautiful code skills and well balanced technical design skills. Team (b) includes non-technical business process nerds who will follow a process to their grave because they have no other choice.

If you give both teams a one page document on the required scope for a system, and 10 days to create a prototype, which will produce something useful?
Add a single developer to team (b) and you have the current recipe for how most business systems are created (like crap). Add a single good project manager / Systems Analyst to team (a) and you have a world class system, software product, or game (and you may well have had one with out the addition).