I love to write code. I am 49 years old and have been programming off and on from 1977 – 1990 and as a fulltime professional since 1991. I hesitate to even guess how many programming languages I have used over that time frame. Since I love to program, not only was I using several different programming languages at various jobs, I was also experimenting with several others after work.
I don’t do as much “on the job” programming as my role has been a “Software Architect” for several years now, but I still do a fair share and even more so in my spare time. For example, I released an open source project that I have been working for the last two years called Global System Builder. It was supposed to be fun, but that is the crux of the issue I am having – it was mostly a lot of really hard work. Not that it was technically difficult, but seemingly something very simple turned out extremely hard to do.
Let me digress a moment to illustrate a point. As the domain name of this blog indicates, I was progressing in programming languages as the level of abstraction was being raised over time. Meaning in modern day times, not worrying about memory management, ala garbage collection in languages like C#, enjoying the REPL feel of dynamic programming languages (e.g. IronPython and IronRuby) and marvelling at the power of functional languages (e.g. F#) and then...
I came to the realization that as time marches on, rather than programming becoming easier (read: simpler) it was actually becoming more complex, to the point where today even to write anything simple seems to take a monumental effort, and seemingly more configuration effort than programming, and with so many moving parts, fraught with errors that are not compile time related. I felt this not only in my professional software development world that I live in, but even on the open source project I was working on in my spare time for fun. And it was supposed to be fun, but instead it was a design exercise at every turn figuring out which of the programming languages, frameworks, components, and widgets I could use that were the lesser evil since none of them did what I wanted them to do. As you will see, this is the irony.
Sure we use all sorts of frameworks today that supposedly make our programming lives easier. The one I am most familiar with is the .NET framework. At +11,000 types and +100,000 members, I am overwhelmed by the sheer size and complexity of the framework. I can barely wrap my head around 7 +- 2 items let alone several orders of magnitude larger in size and complexity. I spend more time looking at MSDN documentation trying to figure out how some Type works and the members I can use rather than actually writing code.
The argument is that we become more productive cause “it is taken care of in the framework” My experience and others would tend to disagree from a practical perspective and let alone the simple math truth. Our brain is not designed to juggle thousands of Types and so we spend a great deal of time, searching, looking up docs, figuring out what to use from a design perspective, looking at the samples from an implementation perspective, looking at how others have used it – only to find that while it is close to what I want, it does not really meet my requirements. Fine, close enough and with a few overrides, no problem. But when you get into low level design and implementation, you run into hard stop limitations and then you a) try and find ways around the limitations or b) go back to the drawing board or c) think about not programming anymore.
And so ends the digression. The point being, as told by Charles’s Petzold, “Does Visual Studio Rot the Mind” under the subtitle, “The Pure Pleasures of Pure Coding”, where he states, “...but there’s no APIs, there’s no classes, there’s no properties, there’s no forms, there’s no controls, there’s no event handlers, and there’s definitely no Visual Studio. It’s just me and the code, and for awhile, I feel like a real programmer again.”
At last we arrive at why I am possibly deciding not to code anymore. There is so much in the way and there is so much “of it”, that doing anything simple has become an incredibly complex task and doing anything complex takes teams of software folks to deliver due to the sheer size and complexity of our own programming environments, let alone trying to solve the problem domain we have been given.
Here comes the “I remember at time when...” Love it or hate it, Visual Basic 6 (or the Delphi equivalent at the time) was the most productive programming language and toolset I have ever worked with (Digitalk Smalltalk takes 2nd place) for building business applications in the last 17 years I have been doing software development. Why?
I used to do storyboards right in the VB6 IDE asking the business guys what they wanted, “so you need a form, with a list box and what should be in the list box, and when you clicked ok, now what... “And on it went. In a couple of days to a week, we basically had the front end of the application prototyped. Since it was back in the “two tier” days all we had to do was hook it up to the database. And if we got really “fancy”, (or had the luxury), we added a third tier of business logic written out as VB6 classes, not in the stored procs, and after a bunch of testing, report writing, etc., boom! off it goes into production.
There were a lot of happy people back then. The business users were happy because they got to sit in and basically design the user interface with me while trying to figure out the app. And then weeks later it was delivered and did exactly what they wanted it to do. I was happy, along with my team as we got a buzz on from being so productive and delivering what the users wanted. And the tools, language and database was simple enough back then to not to get in anyone’s way. Everyone happy! So what happened?
One part of it is web applications happened. Even in 2008, Visual Studio ASP.NET cannot give you a WYSIWYG view of your web application. Yet, VB1 was able to give us WISYWYG back in 1991! What the heck? Not to just pick on Microsoft, I would say the majority of vendors’ web development tools are like a decade or so behind their “traditional” development tools for building desktop applications. Further the vendors push more and more features, more and more “layers”, which mean more moving parts, which means more complexity, which means making it harder and harder for the programmer to use. It reminds me of the infamous air-conditioning “duct” scene in the movie Brazil.
Our tools and applications have become so large, many and complex, it is literally making us less productive. And to me, productivity is everything. Productivity. It is as simple as that.
Updated: A Programmers Dilemma - Productivity Lost - Part II