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.
Conclusion
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. 
.
but I LOVE text adventures :(
Number 1. A lot of this goes on already. There’s Open Source for one thing. Many of the ActionScript classes that come with Flash and Flex are open for modification. I’m thinking of the Flash 8 core classes, and the patches out there that you have to apply them to get them compatible with the rather stricter MTASC compiler. It would be great if when developers found bugs in such things, they could submit them to Adobe or whoever and the fixes could disseminate through the community by some means other than blogs and lucky Google searches.
Number 2. Programmers in general really need to learn to write documentation, not just for end-users, but for other programmers, to benefit software intended for other programmers to use (tools, components, frameworks, IDEs, etc). Many of the coolest-sounding things out there that I’d love to play with, I can’t get started because I have so little to go on in terms of understanding how it works.
Number 3. You could be on to something with this visual programming thing, and it may be closer than you think. Consider Visual Studio, or the Java IDE plugins for UI design, or even Flex Builder’s design view. These are primarily UI-focused but they do generate code, and it kind of feels like incorporating a visual representation of Flex’s data binding into the Design View would be the next step. Also, remember those Flash 8 components, I forget what they were called, but you’d drag an XMLConnector and some kind of filter icon thing on the stage, and connect them using a dialog that set hooked them up using the Data Binding Classes? That was already kind of close to what you’re envisioning I think, too bad hardly anyone ever figured out how to use them (probably needed more documentation).
The possible downside to this is the generated code itself. Visual programming like this could do a lot, but I get the feeling that there would be edge cases where you’d need to go in and write the code yourself to do what you want — meaning you’re now in the position of having to edit generated code, and generated code is a notorious bitch to read and work with.
4. There’s a limit to how descriptive an error message can get. A compiler or runtime can explain what the error was from its point of view, but usually isn’t smart enough to know *why* it happened. Take for example your previous blog post about the 2032 Stream Error. There are any number of reasons that something called a “Stream Error” could happen — there are many kinds of streams, with file handles being one of them. This reminds me of the tactic I’ve lately taken towards exception handling: any time you can provide more information about what led up to an exception, you should catch it and give information more specific to the point where it was caught. Rather than let it go at “Stream Error,” Flex should have caught that error and done something like “Oh, I got a Stream Error when trying to access a file. So there’s likely a problem with the file I was asked to read. I can report this info in a new error message.” I’ve started using exception chaining in much of my server-side PHP code for this; but OTOH people complain like crazy about the overwhelming long-ass stack-trace exception messages they get from Java where multiple lines of “this exception occurred here because of this other exception here because of this other exception here.” There should be a way of capturing the Exception object and deciding for yourself how much of that firehose you want to sip from with a graphical object that lets you walk down the exception chain something like opening up folders in the Navigator panel.
5. Sorry, I like the proliferation of languages. Each takes its own approach to programming, and each approach seems to eventually find the niches of problems it’s especially good at. Let a thousand flowers bloom!
6. Not sure what you mean here, but there are plenty of good books about general best practices in programming and/or software development. I just finally got around to picking up a copy of The Pragmatic Programmer the other day.
7. The mashup seems to come from the web world, where different parts of an application live in different environments. Some of the application runs in a web browser, some on a server machine, etc. This seems to mesh with #5 unless I’m not quite understanding you right. For instance, development for within web browsers combines different languages because each has its own purpose (HTML for semantic markup of content, CSS for the visual presentation, Javascript for user interaction, XML for representing data). Different technologies/languages exist to do different things, and attempts to make one language do all of it usually result in something that’s not-so-good at some of those things; so then people write frameworks, preprocessors, generators, cross-compilers to make up for it.
8. Unfortunately I don’t think something like this is possible without a central authority enforcing it. Standards bodies exist, but standards are only as good as how much they’re followed. Having them encourages them to be followed when following it is to the benefit of those involved, but you can’t really force total compliance without some kind of oppressive regime.
9. There’s a lot that can be done here by comparing a project to something similar you’ve done earlier, or breaking the project into different parts that you can compare to similar parts of various earlier projects. This is why it pays to record data about the time and resources used in projects for future reference. As time goes on you accumulate more data that can help you make better time/cost estimates, particularly if it can be worked into some kind of automated or partially-automated process. We’ve recently had everyone at T8 go through training on using Microsoft Project, which may not be able to do everything, but it’s a big step in our actually being able to gather this kind of information.
10. I relate this to 5, 7, and 8. APIs are influenced by the organization that they are developed in, the language used to implement them, the times in which they were born, and a lot of other things, so I think this is something that is always going to be with us. It’s why we have things like the Adapter pattern. It’s hard to make something general enough to release for other people to use, yet easy to make specific enough for anyone’s specific use case. In addition though, some code/APIs are better then others and that will always be the case. Quality varies in all sorts of products.