Programming tools for users
February 6, 2011
I have heard that in the olden days, users wrote their own computer programs. Now users were probably scientists and engineers and may have been intimidated by assembly language or whatever was available, but the advantage of user written software is that one doesn’t have to explain what one needs to a second person, the programmer.
Jump forward a few decades. The meat and potatoes CRUD applications of business computing are pretty much all written what we want now are applications that explore direct physical sensors, processes useful to knowledge workers, analytical tools to explore massive data stores and probably others. Take one, knowledge worker processes. It’s hard to explain how we think…
What we need are new programming tools. One for use by non-programmers to express their requirements. That can then be manipulated by the designers to explore how best to express the requirements. That can then be enhanced by programmers to create the best implementation of that design. Tools that are useful for different practitioners at different stages of the process and that know how to hand off the nascent product to each other (in both directions, given the iterative nature of software development).
Current programming languages seem to concentrate on that last phase. That maybe fine for programmers, that’s what we like to do. But perhaps we need to step back and look at the big picture…
Notice that position of design between requirements and programming. In design we need to be able to explore several designs, not just one, and to compare how issues get resolved, or not, among the various designs. Even as requirements, designs, and iterated code evolve.
February 6, 2011 at 5:21 am
One of my early computer experiences was a class on using a financial modeling language. This was back in the day of paper punch cards. The computer program, which ran on a mainframe, created financial models which we would think of today as Excel spreadsheets.
There was a certain beauty in writing dozens of lines of code to create what I can do in a few minutes in Excel. The beauty came in thinking through the logic necessary to tell the computer what you wanted to do and how to print the result.
Excel is one example of an end user, non-programmer tool you speak of. The downside is using a tool without having requirements and a sense of design to create something. PowerPoint makes people think they are presenters. The $40 landscape design software package makes people think they are landscape designers.
I can think of numerous tools for web design and other applications that are supposed to be for the user to create their own applications or designs. Unfortunately things often do not turn out as expected.
It really depends on the expectations for the result. Often the end user knows what they want but they just don’t know how to express it or create it. But I think having the ability to understand your requirements and logically think through one or more design concepts are a prerequisite to using a tool regardless of what you are developing.