Hackers and the Beautiful System

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).

A Personal Journey To Find The "Meaning" Of Software Development

I believe that I was born to be a computer programmer. Somewhere, deep in my soul, there is a need to organize my thoughts in ways that are both new and interesting, but also foundational and reusable at the same time. I've always felt that there is something atypical about this kind of work, and about the people who have chosen to do it. Not that it is better or worse than any other profession mind you, but that it was very unique, and at the same time both interesting and powerful.

However over the years, I have learned that this is not exactly a commonly-held belief.

Years ago (it seems like another lifetime now), a manager of mine was adamant that we create a "software development factory". This person worked in Information Technology, but was never a programmer. This person (hence forth referred to as "IT") was in love with "process". "IT" had worked up through the I.T. ranks as an analyst at first, but had been able to cultivate the right look and absorb the right words to be promoted through past similar personalities into a position of real power. At this one historic moment, "IT" was in the driver-seat of a team of managers and developers. I was one of them. The problem was, "IT" had no had no idea what our jobs entailed. Since "IT" did not like to think there was a concept,"IT" did not understand, "IT" decided to "improve" the team. "IT" had the bright idea that we should take a team of developers and create a "factory" out of them. In this person's mind, programming was a rote exercise that could be turned into a repeatable process. In "IT"'s view, programming did not take any real thinking. You took inputs, processed them, and created outputs. "IT" believed this was the most menial work possible, only important enough to be treated in the most dismissive of ways.

Suffice to say, "IT" and I did not get along. However, instead of rolling over, I tried to fight back.

• I argued up and down, and down and up, left ways and right ways that my team of developers were not factory workers, and they did not create widgets.
• I explained over and over that each project was different and required a unique solution that could not be picked off a shelf and plugged-in automatically.
• I created 100 page documents that described in detail how software development worked and how it was more iterative and creative than simply straight-forward and rote.
• I created diagrams of every type imaginable showing the tools, the process, and the creative thinking that went into designing software.
• I pasted images of all our work on the walls and in the conference rooms.
• We adopted SCRUM and Extreme Programming methodologies to show that development was iterative and not simple a step-by-step process,
• I hung statements from notable software designers and developers in the hallways.
• I brought in great software developers to teach classes on design and creative software development

In the end, of course, it did not work. I was demoted. My team was cut in 1/2, then 1/2 again. Work was outsourced. When it stayed internal, it was done by generic contractors instead of the type of hand-picked software wizards I knew would make the best developers. Quality slipped, and so did deadlines. The super-effective and proud team that I once led was turned into a hallow carcass.

This proved to me that there is a common misconception about what software development really entails. I'm not talking about "software support", but real, honest programming. Truthfully, I don't think many people outside of core development circles understand how software is made, or what it means to the people that do it. Worse, this misunderstanding is not just superficial. It colors decisions made by people in the highest places of power. It's ill-informed, destructive, and in some cases, could even be dangerous.

A few days ago, I decided to try to find out what other people have written on this subject. I was on a quest to find a way to describe programming that would make someone in "IT"'s position understand the reality of "programming".

I started at he top. One of the masters of computer science, Donald E. Knuth, wrote about The Art Of Computer Programming in 1974 (he is also the author of the widely read multi-volume set of books by the same name) . Knuth chose to describe programming as art:

"My feeling is that when we prepare a program, it can be like composing poetry or music...Some programs are elegant, some are exquisite, some are sparkling. My claim is that it is possible to write grand programs, noble programs, truly magnificent ones!"

"...computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better."

While his ideas on the subject are a close approximation of my own, I needed to try to find some other perspectives as well. With a little more searching I found this great article about Art And computer Programming, by John Littler. It contains many quotes from developers on the subject, as well a very relevant quote from none-other than Albert Einstein.

"After a certain level of technological skill is achieved, science and art tend to coalesce in aesthetic plasticity and form. The greater scientists are artists as well."

While both of these sources were awesome, I was not sure that "art" was the only description I was looking for. Programming may well be an "art" but it is also a "science" too, so just calling it an "art" is not quite accurate. Furthermore, calling it an "art" certainly would not have changed the mind of "IT" . In fact, "IT", being of simple mind (in my opinion anyway) , would have probably just found that idea "elitist", and dismissed it immediately. Because of this, I wanted to find another word that did not seem quite as lofty. I found it a few lines down in Littler's article.

"To me, it relates strongly to creativity, which is very important for my line of work"

This , a quote from Guido van Rossum (the creator of the Python programming language), was getting closer to what I wanted to read. Being "creative" was certainly necessary for art, but it was also necessary for many other pursuits. "Creativity" could describe a beautiful painting, as well as an affective strategic battle plan, or even the solution to complex problem with no clear-cut answer. To me, software development involved at the very least, all three of these things. I decided to follow this line to see where it would take me.

Over at AnswerBag.com, I found that someone named "guitar man" had asked this question: "Is computer programming creative? or is it a just an analytical type process? "

There was one answer, and it came from a guy with the very creative name: "Jeztyr - whispering in the ears of kings" :

"Programming is an art form that fights back. It requires creativity to solve the seemingly unsolvable, and analysis to make it better, faster, more efficient. A lot of programming is mundane, ritualistic stuff, but other times it's rewardingly convoluted."

This answer really hit home with me. I liked the use of the words "creativity" and "analytical" at the same time. However, the best word for me was "convoluted". Some how that word seemed to describe the software development process in a way that I had never considered before. I decided to look-up the word "convoluted" on Dictionary.com. Here is what it said:

con-vo-lut-ed: Adjective: complicated; intricately involved: a convoluted way of describing a simple device.

"Hmm." I thought. I then looked at the synonyms: "elaborate,
intricate,
involute,
involved,
knotty,
labyrinthine,
tangled,
baffling".

All of these words seemed to point to something that was underlying all of this, but not quite yet on the page. Yes, software development is "intricate" and "elaborate", but the words "tangled" and "baffling" also stood out to me. Those words seemed to describe to me the state of "software development" when you know the problem you need to solve, but you don't yet know how to solve it. It is also the same part of the process that can require a creative "spark" to surmount, and once a solution is in place, the process becomes more scientific. This limbo state of development always seemed to the most "unordered "to me the most...chaotic.

"Chaos."

I then recalled something from our time dabbling in SCRUM (a software process that embraces change instead of pushing back on it). The phase was "controlled chaos". While the SCRUM definition was not necessarily what I was looking for, the term seemed to be appropriate. Software Development was an ever-evolving process of taking chaos and creating order. Creating order from chaos is not an easy thing to do, but it is something that certain individuals (including many talented programmers) thrive upon.

I searched for some thoughts on this, and I found one that was so blunt and and final, even "IT" could have internalized it. Software Engineer Robert L. Glass described his role this way:

"Eat Chaos, Poop Order."

In the most base way possible, Glass had crystallized my thoughts on software development. He continued to clarify his position.

"Chaos and order are the theme of my life. I consume one and produce the other."

I could not agree more.

At this point, I seemed to have come to the end of my journey. All of these quotes I had found sort of swirled around in my head until I came to a realization of what it all meant to me, and it is the following:

"Programming is at once, both disciplined, and undisciplined . You must follow some rules, but also strive to break others if you want to make breakthroughs and discover new ways to make better software. It truly is art and science mixed, however the amount of each depends on the problem you are trying to solve. However, there is something else. Programming is like making sense of the senseless. It starts as chaos,and through sheer will of the mind, that chaos is organized into something amazing. It is also a stunningly enjoyable profession that feeds your mind and soul at the same time. In my nearly 30 years of programming experience, the initial surge of energy I feel when sitting down to start developing a new program has never dissipated nor has the sense of satisfaction when the last line of code is written and I hit the [Enter] key for the final time. If anything, the process has only grown greater and more important as the years slip by. In the final analysis, far from being a rote exercise, creating software just might be the the ultimate creative medium. With the proper knowledge, creativity, and computer power, you can build almost anything you can imagine. "

It was long-winded, but I was satisfied with my answer. However, if I had been able to express these thoughts properly all those years ago, would I have been able to change the mind of someone like "IT", and finally prove the reality of software development to someone in power?

Probably not, but at least I proved it to myself.