Every now and then, articles pop up about how archaic text based source code is, and how everyone would benefit so much if we'd all switch to graphical code design by dropping little boxes and connecting them with wires. We've heard this story so often before, and yet source code is still the preferred method to write software. Why? There are so many reasons, and they should be obvious.
1. Company X decides to 'draw' all their software in company Y's proprietary tool. Three years down the road, company Y gets bought out, or folds, or drops that product line. All the 'source' code company X has is suddenly worthless, and needs to be converted to something else before the tool stops working on the next generation of computer, OS, etc. This problem does not exist with text based source code. At most, you need to change a couple of vendor specific pragmas or attributes and you're set. Text can be handled by any software on the planet, unlike proprietary formats. I would highly question any product manager who does not worry about this.
2. When projects start to reach a certain size, graphical methods become an unintelligible mess. Take as an example what happened to CAD used in chip design. Chips used to be designed using schematics. But when chip sizes grew, this graphical method became unmanageable. So text based design methods like VHDL and Verilog, and later even higher level methods like SystemC were invented to deal with this. All text based. Why? Because that works well for large systems.
3. There is a reason civilizations moved from wall paintings, pictograms and hieroglyphs to character based language. Our brains seem to be hard-wired to deal with language. Using language to describe something is the natural way to learn to understand it. There is a direct link between text and language. There is no such link between drawn symbols and language. Try to tell a colleague there is a bug in the assignment on line X of file Y. It's easy. It's precise. There is no question about what is meant. Now try to do the same in a graphical design. "The addition box above the big square on the bottom left..." ??? It gets even worse when you have a bunch of wires running from one side of the page to the other. It's way too easy to loose the one you were trying to follow. Well written source code on the other hand can almost read as easy as plain text.
5. I think that very often it is the managers who like graphical input methods and push it on their team, because they can't read source code, but can to some degree understand pictures. Indeed, to outsiders a simple diagram may be clearer, especially if you just look at the top level diagram and don't worry about the mess hidden beneath each of the pretty boxes. But I feel sorry for the developers who are now forced to suffer through implementing all the lower level functionality in those boxes in a way that is alien to them. A manager who makes his team miserable and reduces their productivity just so he can have a semblance of understanding what they are doing is a poor manager indeed. A good manager empowers his team and trusts them instead.
6. There is a huge ecosystem of tools built around text based code. Simple example: version control. It is so easy to track what changes happened to your code between different versions. Are there any such tools for graphical entry, tools that show graphically which connection got changed, how the internal structure of a block changed, etc?
As much as some companies would like software developers to jump on the graphical entry bandwagon and make them a fortune, the fact is that text based source code is here to stay. It's proven, works well, and takes advantage of all the language wiring in our brains. What's not to like?