I’ve been in software for a while and I decided I would mention the things that affect the ability for me to do my job and address them. I mention the problems because I think there are solutions to them.
On a high level the path to programming is such.
1. what do i want to do?
2. how do i do it?
3. why didn’t it work?
This is my top ten list of the problems with programming. Each has taken huge chunks of time. Sometimes days are spent scouring the internet or posting to forums for an example of what I need. Sometimes it is a lack of documentation or support other times it is a bug. Both these issues can be solved by trained support but others listed below are more complex.
The first few items all tie for the top position. Anyway, on to the list.
1. Bugs – Bugs cause more problems for me than any other thing in programming. Bug fixes should be a number one priority. Why? Because unless it is minor you can’t finish your project until it is fixed. Waiting a year and a half for version 2 does not work. Until they can be fixed a list should be posted in an easy to find fashion. For example, a bug that prevents property X from working in Component Y should be listed on a page under Component Y > Property X > Bug. A solution for fixing bugs between major releases should be made. A possible solution to this is to allow the community or a subset of the community access to the source code to provide a patch.
2. Lack of Documentation, Examples & Support – The best software is useless without instruction how to use it. Documentation illuminates the knobs, switches and levers available to you. Examples are like sitting with an instructor as he shows you how to use them. In some fields you can get away without instruction by making an intuitive interface (for example a light switch). In programming you have to have information on usage. At least currently with a text based programming model (see next item). All three of these areas (documentation, examples and support) are essential.
3. Non visual. This is my second biggest complaint. I wish programming was more visual. In other environments there are icons and visual clues that represent what things are and what they do. Give more representation to objects, classes and variables. Show the non visual objects on the stage! Show me an imported class and let me drag and drop its property onto a text input. Let me add a validation object to the stage and bind it to that text input. You can see this in some 3d programs and database programs. So on the stage you would have a Validation icon with a target property and you would have a text input with a text property icon. You would drag the target property icon to the text input text and a visual line indicating a “binding” has been made. So in this example you are typing less. But you say, the screen might get cluttered. Sure, it could. Thats the least problem. Scroll the view like you do in a text document or make an option to hide some or all visual items. Problem solved. The benefit far outweighs any temporal issue. For example, make an panel that lets me see and hide all “validation” objects, “bindings”, “classes”, “imports”, etc.
Think about other environments. If you have an blue box in Photoshop or Illustrator and you want to add a border around it you don’t go into a code view to type “border: 1px solid #ff0000;” do you? If you want to add a text field to an image you are working on you don’t go into a code view and declare a new text field, set the text, set the x and y and set the width and height. You drag it from a components panel or draw it out with a text tool, type in the text and resize it and position it. If you need to move it you drag it around. The position, size, width, height and so on are all updated dynamically as you interact with the design view. Now if you’d like to see or modify the code that it writes thats fine. We can have and need one that will write our code for us. But if we have an object, lets say a class, to be able to drag it to the stage and it would show up as a circle or box. Then I hit a key and all its properties and methods appear branched out around it or in a panel. Then I can drag and drop and connect the properties like you would connect tables on their keys. Now that would be fantastic.
Note: This is really where I want things to change. One day I hope myself or someone else has enough resources to create a visual development environment similar to what I’ve been trying to convey.
4. Non-descriptive error messages – When we get error messages there has got to be an explanation for them. What does error “10123948B” mean? Can you explain in human terms what the error message is and what to do to fix it? Not just to me but for any user that might see it. Maybe we can make a global errors database. Program > Error Number > Language > Error Description > Error Solution.
5. Language barrier learning curve – Make programming language more understandable. Make them less cryptic. Make the language more abstact. More easy to read. In English we have synonyms. They are two words that mean the same thing. In programming you can’t get a B+. You can’t get get a A. You have to get an A+. Things have to be typed exactly the way the compiler wants it. I’m talking about the syntax we’ve all learned to accept. Define abstract programming languages in to differing classifications or metaphors. For example, an english student can understand english language constructs. If we told this student that methods are the same as verbs and properties are the same as adjectives and nouns are the same as objects or classes they will instantly have a foundation to relate to. This would help it make sense to the student. Set up nomenclature for description of programming words and concepts. Languages and syntax can be abstracted but a guide can be made against the standard. Where what equals what. Then different metaphors and abstractions can be used.
6. Best practices – This ties in with Lack of Documentation, Examples and Support. Many rookies and rookie technologies emerge. It is not always known what the best practice or the recommended model for development should be. This usually leads to misappropriated feature requests, break off frameworks and numerous method factions. This information needs a residence and place with its technology.
7. Mashup of technologies – Create tools to handle the complete production of an application. Many people say use the right tool for the right job. When you have many different technologies then you can choose the best among them. This is a good idea but at the same time there is detachment from one piece of code to another. There are no constraints or error checking across tools. Using a single development tool to bring a application from start to finish is the way it is supposed to be. There are many reasons everything is broken up now into several separate programs. There is a multitude of technology created to run on the multitude of hardware. Each program should be the complete start and finish of its solution. This is unrealistic in some fields but this is not impossible. When you make an online application you should be able to make the front end and the backend and deploy it as one file to the server. It should not be as difficult as it is. This is really a problem with the current state of online development. This may go away in the future.
8. Differing rendering and operating system – Standards. Browsers and operating systems should be application agnostic. Applications should be operating system and browser agnostic. They should be written to once and they should be able to be run anywhere. So many differences between browsers make web development a nightmare and sometimes impossible to get a site to look and function the same across all browsers. The same for applications on different operating systems, which is they either work or they dont.
9. No Accurate measure of Timeframe. Unless you have done something before there is no accurate estimate of the time it will take. It is safe to bet it is around 3 times as long as you estimate if do not run into any of the problems mentioned here.
10. Different API’s – When using differing tools it can be hard to combine the two. Try to follow a standard if one exists. Keep components using the same architecture. Never hardcode a value. Always make it easy for someone to extend or wrap your code or component. Coding is like an art. But if your art is a tool then you have to consider your users.
Remember in the 80′s we had those Text Adventures. Everything was text based. To move you would have to type where you want to go. “Go North”, “Go South”, “Pick up item”. With the progress we’ve been making now you no longer have to type text go where you want. I think in the same way. We can get to a place where we don’t have to type text to make programs. This will involve creative thinking but I think its possible. I think we can get to a point where we could make a class by dragging it from a panel. Then drag properties on top of it and type in their name. I do not suggest we do not use code but rather have a rapid application visual design where the code compliments it. .