Improving Software

In his satirical and quite humorous article, “How to Write Unmaintainable Code,” Roedy Green raises an interesting question that really got me thinking about some things I had previously taken for granted with the the physical act of creating software.

“Why is programming still done primarily in a text editor?” 

 Before get rolling with my analysis of this question, please take a moment to read his conjecture on the topic. I’ll meet up with you again at the the other end.

Imagine having an accountant as a client who insisted on maintaining his general ledgers using a word processor. You would do you best to persuade him that his data should be structured. He needs validation with cross field checks. You would persuade him he could do so much more with that data when stored in a database, including controlled simultaneous update.

[Now] imagine taking on a software developer as a client. He insists on maintaining all his data with a text editor. He is not yet even exploiting the word processor’s colour, type size or fonts.

Think of what might happen if we started storing source code as structured data. We could view the same source code in many alternate ways, e.g.  as a decision table, a flow chart, a loop structure skeleton,  Java with various levels of detail or comments removed, as Java with highlights on the variables and method invocations of current interest, or as Java with generated comments about argument names and/or types.  You could see code with additional or fewer parentheses, (depending on how comfortable you feel with the precedence rules).

You could use the full colour abilities of the modern screen to give subliminal clues, e.g. by automatically assigning a portion of the spectrum to each package/class using a pastel shades as the backgrounds to any references to methods or variables of that class. You could bold face the definition of any identifier to make it stand out.

You could ask what methods/constructors will produce an object of type X? What methods will accept an object of type X as a parameter? What variables are accessible in this point in the code? By clicking on a method invocation or variable reference, you could see its definition, helping sort out which version of a given method will actually be invoked.You could do quite a bit of code writing by point and click.

He has some interesting points, doesn’t he? The comparison to an accountant using a word processor to create journal entries really struck me. I began to think about the Sisyphean labors of applying language/compiler specific markup in our code to satisfy our brutal task-master. It is easy to start thinking about programming IDE’s and compilers as a special class of software that is exempt from the normal  usability considerations because it is geared towards computer experts, but that just isn’t true.

Put Themselves in our Shoes

Consider the reaction of your users if you required them to enter data in your application using a big text-box using well-formed XML to provide context and meaning to each individual item. Sure they’d complain because they can’t remember the relevant attributes and always forget to close their tags, but that would be easily solved by updating the text box to have Intellisense!

Actually, no it wouldn’t. Clearly the intellisense solution addresses only the symptom, not the problem.

We Deserve Better

So why is it good enough for us?  Don’t programmers deserve good usability in our tools too?  Is it really necessary to spend valuable time matching up brackets/parens and chasing down missing line terminators?  Worse yet, if you frequently use different languages, the mental context switches force you into all sorts of mental gymnastics to keep it straight,  and incite a scolding from your compiler.

Why do we have to keep syntax ideosynchracies in our heads?

var myInteger //This is a Javascript comment
Dim myInteger as Int 'This is a VB comment
int myInteger  //This is a Java or C++ comment
myInteger=5 # This is a Ruby Comment
DECLARE @myInteger int --This is a t-SQL comment

Creating good visualizations for scoping, variable declaration and module interfaces is not an unsolvable problem. Also, the benefits of one more level of abstraction extend beyond increased productivity. For example, consider the portability that the increased normalization of code could produce.

Or Maybe Not…

At this point I am sure that many of you are still skeptical, and I am about to slam the door on the open mind of the remainder of you. What I am describing here is effectively form-based (a.k.a “drag and drop”) programming.

That Whooshing is the sound of this article entering free-fall from angry programmers down-voting it on Reddit.

This is exactly why we are still programming in glorified text-editors, because that is exactly what we want. And unlike programmers who write software for marketing people, the developers who create programming languages and IDE’s understand very well that other programmers emphatically prefer some additional complexity to even the remote possibility of democratizing software development.

Homework Assignment

As a mental exercise and preview of the finale of this article, consider this diagram showing the general sense of  superiority among programmers in the style of the famous Geek Hierarchy poster and ask yourself which direction the arrow would go in terms of general usability of the tools for each type of programmer.

Hierarchy of the World According To Programmers

To be Continued…

In part two of this series I discuss the psychological and frankly pragmatic reasons that our techno-brethren are so committed to keeping the field of programming as exclusive and specialized as possible.

Filed under: The Software Development Process | Tagged: programming, technology |