Monday, June 04, 2007
The Dumbing Down of Programming
Awhile back, I asked is programming business applications are boring? and came to realize that one dimension of why they are starting to become more bording is due to the overall trend of dumbing down programming...
Dumbing down anything lets more folks participate and that is bad if comprimised have been made to limit what experts can do. In order for outsourcing to places such as India, programming has to be dumbed down even more. When combined with Bell Curve Compensation, the need to dumb down IT becomes even greater.
Real programming is hard especially in languages who on the surface appear simple. Ever wonder why Ruby on Rails isn't being adopted for mission-critical enterprise application development by Fortune enterprises whose primary business model isn't technology? If you have ever ran across pretty much anyone in the Ruby community, if the language doesn't have a feature, they are usually more than capable of filling in the blanks themselves which is a skill not usually encouraged within an enterprise environment and therefore enterprises must have strategies that on the surface sound good but also where the masses strive for Underachievement.
So far, the below assumptions have so far proven true, but need not be true. Consider...
1. Lower-level interfaces (in the form of programming language -or- operating system) typically provide tools for performing very simple, but very specific, tasks. In order to accomplish anything substantial, you need to utilize many of them, and thus you need to understand many tools in great detail.
2. Higher-level interfaces typically provide tools that are more powerful, in that they accomplish a wider range of actions. Usually they're automated, so that, given simple (often more intuitive) input, they perform many complex, low-level functions. However, their automation is also their weakness: it's often difficult or impossible to customize the tools to do something different. So at times, it can feel like you're trying to club a fly with a huge rock, when a simple flyswatter would prove so much more effective.
Anyway, the argument in both cases usually boils down to an argument between the "power users" who have spent days/months/years/decades learning the specifics of a low-level interface, and who can accomplish really amazing feats because they're highly skilled; vs. the "average users" who want to spend as little time as possible learning the interface and just use it for everyday tasks with minimum hassle. Neither side can claim a moral high ground, and neither is inherently correct. Any interface must be able to perform very complex, robust actions, but should be simple, intuitive, and easy to pick up for the simple, day-to-day tasks (and users.)
The funny thing is that while outsourcing requires dumbing down, one could incorrectly draw parallels to enterprise architecture. In reality, enterprise architecture is more about simplification than dumbing down as it takes very intelligent folks to simplify things. It took a lot of intelligent people and time to go from manual tasks to dedicated hardware for tasks to programmable hardware to software to 1st, 2nd, 3rd, 4th generation programming languages, etc. It has taken a lot of intelligent people to move computers from the realm of the scientist to where 5 year olds and grandmothers can surf the web. Simplification is hard work and we should take pride in making things simpler. I doubt any enterprise architect worth their salt could truthfully refer to outsourcing as simplification.
| | View blog reactionsDumbing down anything lets more folks participate and that is bad if comprimised have been made to limit what experts can do. In order for outsourcing to places such as India, programming has to be dumbed down even more. When combined with Bell Curve Compensation, the need to dumb down IT becomes even greater.
Real programming is hard especially in languages who on the surface appear simple. Ever wonder why Ruby on Rails isn't being adopted for mission-critical enterprise application development by Fortune enterprises whose primary business model isn't technology? If you have ever ran across pretty much anyone in the Ruby community, if the language doesn't have a feature, they are usually more than capable of filling in the blanks themselves which is a skill not usually encouraged within an enterprise environment and therefore enterprises must have strategies that on the surface sound good but also where the masses strive for Underachievement.
So far, the below assumptions have so far proven true, but need not be true. Consider...
1. Lower-level interfaces (in the form of programming language -or- operating system) typically provide tools for performing very simple, but very specific, tasks. In order to accomplish anything substantial, you need to utilize many of them, and thus you need to understand many tools in great detail.
2. Higher-level interfaces typically provide tools that are more powerful, in that they accomplish a wider range of actions. Usually they're automated, so that, given simple (often more intuitive) input, they perform many complex, low-level functions. However, their automation is also their weakness: it's often difficult or impossible to customize the tools to do something different. So at times, it can feel like you're trying to club a fly with a huge rock, when a simple flyswatter would prove so much more effective.
Anyway, the argument in both cases usually boils down to an argument between the "power users" who have spent days/months/years/decades learning the specifics of a low-level interface, and who can accomplish really amazing feats because they're highly skilled; vs. the "average users" who want to spend as little time as possible learning the interface and just use it for everyday tasks with minimum hassle. Neither side can claim a moral high ground, and neither is inherently correct. Any interface must be able to perform very complex, robust actions, but should be simple, intuitive, and easy to pick up for the simple, day-to-day tasks (and users.)
The funny thing is that while outsourcing requires dumbing down, one could incorrectly draw parallels to enterprise architecture. In reality, enterprise architecture is more about simplification than dumbing down as it takes very intelligent folks to simplify things. It took a lot of intelligent people and time to go from manual tasks to dedicated hardware for tasks to programmable hardware to software to 1st, 2nd, 3rd, 4th generation programming languages, etc. It has taken a lot of intelligent people to move computers from the realm of the scientist to where 5 year olds and grandmothers can surf the web. Simplification is hard work and we should take pride in making things simpler. I doubt any enterprise architect worth their salt could truthfully refer to outsourcing as simplification.
