…playing off the name of an old Bangles tune…
I ran across a case in point for this, thanks to James Robertson’s blog. Steve Jones is talking about the current state of the art in the organization of IT software development:
So why do I choose to have strict contracts, static languages, early validation of everything and extremely rigorous standards applied to code, build and test? The answer was nicely highlighted by Bill Roth on his post around JavaOne Day 1, there are SIX MILLION Java developers out there. This is a clearly staggering number and means a few things.
- There are lots of jobs out there in Java
- Lots of those people are going to be rubbish or at least below average
But I think this Java groups (sic) is a good cross section of IT, it ranges from the truly talented at the stratosphere of IT down to the muppets who can’t even read the APIs so write their own functions to do something like “isEmpty” on a string.
The quality of dynamic language people out there takes a similar profile (as a quick trawl of the groups will show) and here in lies the problem with IT as art. If you have Da Vinci, Monet or even someone half-way decent who trained at the Royal College of Art then the art is pretty damned fine. But would you put a paintbrush in the hand of someone who you have to tell which way round it goes and still expect the same results?
IT as art works for the talented, which means it works as long as the talented are involved. As soon as the average developer comes in it quickly degrades and turns into a hype cycle with no progress and a huge amount of bugs. The top talented people are extremely rare in application support, that is where the average people live and if you are lucky a couple of the “alright” ones.
This is why the engineering and “I don’t trust you” approach to IT works well when you consider the full lifecycle of a solution or service. I want enforced contracts because I expect people to do something dumb maybe not on my project but certainly when it goes into support. I want static languages with extra-enforcement because I want to catch the stupidity as quickly as possible.
He concludes with:
This is the reason I am against dynamic languages and all of the fan-boy parts of IT. IT is no-longer a hackers paradise populated only by people with a background in Computer Science, it is a discipline for the masses and as such the IT technologies and standards that we adopt should recognise that stopping the majority doing something stupid is the goal, because the smart guys can always cope.
IT as art can be beautiful, but IT as engineering will last.
I like that Jones stresses testing. I realize that he is being pragmatic. He has to use the hand he’s been dealt. He is sadly mistaken though when he calls his approach “engineering” or a “discipline” in any modern sense of the word. Engineering today is done by skilled people, not “muppets”. The phrase “IT as art” is misleading, because it implies that it was made the way it was to satisfy a developer’s vanity. Good architecture is nothing to sneer at (it’s part of engineering). His use of the phrase in this context shows how useless he thinks good software architecture is, because most people don’t understand it. Well that sure is a good rationale, isn’t it? How would we like it if that sort of consideration was given to all of our buildings?
And yes, we can “cope”, but it’s insulting to our intelligence. It’s challenging in the sense that trying to build a house (a real one, not a play one) out of children’s building blocks is challenging.
I guess what I’m saying is, I understand what Jones is dealing with. My problem with what he said is he seems to endorse it.
In a way this post is a sequel to a post I wrote a while ago, called “The future is not now”. Quoting Alan Kay from an interview he had with Stuart Feldman, published in ACM Queue in 2005 (this article keeps coming up for me):
If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort—but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
Egyptologists have found that the ancient Egyptians were able to build their majestic pyramids through their mastery of bureaucratic organization. They had a few skilled engineers, foremen, and some artisans–skilled craftsmen. Most of the workforce was made up of laborers who could be trained to make mud bricks, to quarry and chisel stone into the shape of a rectangle, and could be used to haul huge stones for miles. They could not be trusted to construct anything by themselves more sophisticated than a hut to live in, however. It took tens of thousands (though estimates vary wildly on the magnitude) of laborers 10-20 years to build The Great Pyramid at Giza. It was inefficient, the building materials were difficult to work with (it took careful planning just to maneuver them), used a LOT of building material, and was very expensive.
I don’t know about you, but I think this matches the description of Steve Jones’s organization, and many others like it. Not that it takes as many “laborers” or as long. What I mean is it’s bureaucratic and inefficient.
Alan Kay has pointed to what should be the ultimate goal of software development, in the story of the planning and building of the Empire State Building. I believe the reason he uses this example is that this structure is more than twice as tall as the ancient pyramids, uses a lot less building material, has very good structural integrity, used around 4,000 laborers, and took a little more than 1 year to build.
He sees that even our most advanced languages and software development skills today are not up to this level. When he rated where Smalltalk was in the analog of history, he said it’s at the level of Gothic architecture of about 1,000 years ago. The problem is ancient Egyptian pyramid architecture is about 4,500 years old. That’s the state of the art in how software development is organized today.
I recently talked a bit with Alan Kay about his conception of programming in an e-mail conversation. I expected him to elaborate on his conception of OOP, but his response was “Well, I don’t think I have a real conception of programming”. His perspective is “most of programming is really architectural design”. Even though he invented OOP, he said he doesn’t think strictly in terms of objects, though this model is useful. What this clarified for me is that OOP, functional, imperative, types, etc. is not what’s important (though late-binding is, given our lack of engineering development). What’s important is architecture. Programming languages are just a means of using it.
As I mentioned in my last Reminiscing post, programming is a description of our models. It’s how we construct them. Buildings are built using appropriate architecture. We should try to do the same with our software.
What Kay was getting at is our languages should reflect a computing model that is well designed. The computing model should be about something coherent. The language should be easy to use by those who understand the computing model, and enable everything that the computing model is designed for. Frameworks created in the language should share the same characteristics. What this also implies is that since we have not figured out computing yet, as a whole, we still have to make choices. We can either choose an existing computing model if it fits the problem domain well, or create our own. That last part will be intimidating to a lot of people. I have to admit I have no experience in this yet, but I can tell this is the direction I’m heading in.
The difference between the pyramids, and the Empire State Building is architecture, with all of the complementary knowledge that goes with it, and building materials.
The problem is when it comes to training programmers, computer science has ignored this important aspect for a long time.
Discussing CS today is kind of irrelevant. As Jones indicates, most programmers these days have probably not taken computer science. The traditional CS curriculum is on the ropes. It abandoned the ideas of systems architecture a long time ago. Efforts are being made to revive some watered down version of CS via. specialization. So in a way it’s starting all over again.
So what do the books you can buy at the bookstore teach us? Languages and frameworks. We program inside of architecture, though as Kay said in his response to me, “most of what is wrong with programming today is that it is not at all about architectural design but just about tinkering a few effectors to add on to an already disastrous mess”. One could call it “architecture of a sort”…
In our situation ignorance is not bliss. It makes our jobs harder, it causes lots of frustration, it’s wasteful, and looked at objectively, it’s…well, “stupid is as stupid does”.
Did you ever wonder how Ruby on Rails achieves such elegant solutions, and how it saves developers a lot of time for a certain class of problems? How does Seaside achieve high levels of productivity by the almost miraculous ability to allow developers to build web applications without having to worry about session state? The answer is architectural design, both in the computing/language system that’s used, and the framework that’s implemented in it.
The problem of mass ignorance
I had a conversation a while back with a long-time friend and former co-worker along the lines of what Jones was talking about. He told me that he thought it was a waste of time to learn advanced material like I’ve been doing, because in the long run it isn’t going to do anyone any good. You can build your “masterful creation” wherever you go, but when you leave–and you WILL leave–whoever they bring in next is not going to be as skilled as you, won’t understand how you did what you did, and they’re probably going to end up rewriting everything you created in some form that’s more understandable to themselves and most other programmers. I had to admit that in most circumstances he’s probably right, in terms of the labor dynamic. He does like to learn, but he’s pragmatic. Nevertheless this is a sad commentary on our times: Don’t try to be too smart. Don’t try to be educated. Your artifacts will be misunderstood and misused.
I’m not trying to be smarter than anyone else. I’m genuinely interested in this stuff. If that somehow makes me “smarter” than most programmers out there (which I wish it didn’t), so be it.
History shows that eventually this got worked out in Western civilization. Eventually the knowledge necessary to build efficient, elegant, strong structures was learned by more than a few isolated individuals. It got adopted and taught in schools, and architecture, design, and building techniques have improved as a result, improving life for more people. The same thing needs to happen for software.
I think what’s needed is a better CS curriculum, one that recognizes the importance of architectural design, thinking about computing systems as abstractions–models that are universal, and most importantly gets back to seeing CS as “a work in progress”. What distresses me among other things is hearing that some people believe CS is now an engineering discipline, as in “stick a fork in it, and call it done.” That is so far from the truth it’s not even funny.
Secondly, and this is equally important, the way business manages software development has got to change. Everything depends on this. Even if the CS curriculum were modified to what I describe, and if business management hasn’t changed, then what I’m talking about here is just academic. The current management mentality, which has existed for decades, puts the emphasis on code, not design. What they’re missing is design is where the real bang for the buck comes from.
—Mark Miller, https://tekkie.wordpress.com