Stupid Human Programming
Talk on software development.








Subscribe to "Stupid Human Programming" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.


Saturday, April 12, 2003
 

Interesting article on the role of higher level langauges in increasing productivity. http://www.paulgraham.com/lib/paulgraham/sec.txt. Specifically the use of lisp as a competitive advantage for viaweb is detailed. Viaweb later became yahoo stores.

If you think assembly is higher level and more productive than machine langauge, that C is higher level and more productive than assembly, that smalltalk is higher level and more productive than C, then it stands reason that there even higher level langauges that are even more productive.

Often the next level of languages are domain specific. In the not so distant past there used to be a philospohy of development where problems were solved by inventing new little languages. For some reason we don't do that anymore and i don't see anyone suggest it. Now I don't even try to push it because nobody understands what i'm talking about.

In fact, we have the opposite trend in XP where a new focus has been put on the code. The constant human production and transmogrification of code. Not that there's anything wrong with that. As a means of producing good working code, XP is excellent.

But if we are always tied to humans how are we going to make any progress? The bulk of the human genome was sequenced in a year. Once automation was introduced. Over a decade was spent on sequencing with very little result.

With nanotechnology we may be able to build things like tables automatically, in the same way things like humans are made.

Yet, in programming we will still be depending on humans to produce vast quantities of complex, mostly bug free code. With XP we have improved the process, but it's like we have perfected the process of making the buggy whip just before the introduction of the car. Except in programming there is no invention like that car on the horizon.

Many are trying to shift development to cheaper areas as a way to scale and reduce costs. This is the human as programming robot paradigm. We have lots of people who will work for cheap spread throughout the world. To the masters of business they are just human programming robots. As a strategy we don't know if it will work yet. And even if it does it won't scale into the future. Even if we could enslave more human robots it's unlikely enough working code could be produced.

If you are expecting my grand solution, sorry i don't have one.

Software development seems to be intimately tied with thinking. Thinking has proven tough to automate. And even for machines capable of thinking, like humans, it has been difficult to produce reliable reproducable success.

We don't expect to make machines that can duplicate the efforts of einstien, newton, or da vinci. There are very few world class singers and musicians. These people are assumed to have talent. A talent that even very hard work can not hope to match.

Perhaps software development is also a talent. We don't recognize it as a talent because on the surface programming seems so logical, so scientific.

What does this mean? Many people play music. But there are few world class musicians. Many people study physics. But there are very few newtons. And we don't expect just because someone plays at music or physics that they will be great.

If you have to be great to make software work then we will have to be satisfied with a lot of average performances. If you really want the best then you have to hire the best, the people with the most talent.

Hopefully we will be smart enough to figure out what we are doing and how we are doing it. I wonder how the world would change then?

comment[]

5:31:42 PM    


Frameworks get a bad wrap because everyone has a story about how they were on a project that tried to build a framework and it spiraled out of control and the whole project failed and everyone died a firey death. I contend frameworks fail for pretty much the same reason any other software project fails. If it's not done properly it will fail. If it's done properly yet get a huge ROI.

From dictionary.com:

frame·work Pronunciation Key (frmwûrk) n. 1. A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed. 2. An external work platform; a scaffold. 3. A fundamental structure, as for a written work. 4. A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality.

There's no reason a framework must apply accross multiple applications, there's no reason for it to be OO based, and there's no reason for it to be complete.

My definition of a framework in the context of programming would be something like:

The systemization of a domain expressed in code to solve a particular class of problems in a particular ecology.

The framework could be large or small. It could work in one application or many applications. The primary point is a framework allows developers to solve their problem in terms of the framework. If done well it can provide a lot of leverage (ROI). A framework doesn't solve all problems in every application.

They keys are: 1. Systemization is an experienced based process otherwise the probablity of success is reduced greatly. Experience comes from working on the same or similar problem in multiple projects. It never stops which is why a framework is never perfect and is never done. Systemization is a key to success in other fields and it can be a key in software.

2. The restriction of solving a particular class of problems in a domain is related to notion of ecology. A domain may be very large and have many niches. Solutions (organisms, frameworks, etc) survive best in the niche for which they evolved. Move to a different ecology and the solution will probably die. By being general you weaken yourself against other opponents. It's not realistic to expect a framework to thrive in many niches across many domains.

3. Every project is an ecology. The framework evolves in that ecology and the better adapted it is to the ecology the more chance it has to live and reproduce.

4. As in nature frameworks can catalyze each other to build a much richer world. As in nature there isn't a single hand in charge of creation and coordination, they evolve together in response too each other and to changes in the environement.

comment[]

5:29:14 PM    



Click here to visit the Radio UserLand website. © Copyright 2003 todd hoff.
Last update: 4/12/03; 5:31:48 PM.
April 2003
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      
Oct   May