Wednesday, February 15, 2006

Programming Truth and Fiction

Fiction: HTML is not a programming language. It is a markup language. It lacks all necessary functionality (like if-else branching, variables, loops) to program in it, and in fact, even comparing it to a programming language completely misses the point of HTML’s beautiful simplicity.

Truth: Many managers in IT work environments understand HTML is a kind of programming language. And CSS is, too. Telling them that “HTML programming” is a contradiction in itself will only add to the confusion and should be avoided.

Fiction: In a programming language, you can express your thoughts; you can permanently lay down a rule system which can then be recreated on other machines, over and over. To some extent, the programmer simply manifests a detailed model of how the software is supposed to work, so that this model is turned to “virtual” reality.

Truth: Many IT managers know that programming is the thing that you do in some kind of text editor, with long lines of something called “code” which nobody understands really except the programmer (who was born with the talent of understanding it). It’s a bit like nerd magic, void of real meaning. Most definitely, the actual model of the software is contained in the PowerPoint accompanying the project, not the software itself. At best, the code is a symptom of the model of how the software is supposed to work as detailed in the PowerPoint or Word document – at worst, it introduces bugs on its way to “finalization” of the software.

Fiction: Software needs to be flexible so that changes can be introduced at any time. However, as some changes can’t be foreseen even with the longest discussion with clients, you better get into writing code early on so you have a prototype to show off. It’s up to the programmer’s intuition to solve the non-trivial task of introducing the right level of flexibility into the software. For example, when the programmer believes the web application will need registration at some point, but the client promises this is never needed, the programmer may still create a model that will enable her to easily add this feature in a future revision.

Truth: Your manager can foresee the evolution of the software, precisely and up to 5 floating point digits, using his UML editor of choice and/ or a Word file converted to PDF (converting something to PDF increases its level of authority by the factor of six). As the customer agreed to the feature specifications, there’s no way more features could ever be wanted.

Fiction: The function you write today will turn into a class tomorrow. That class will turn into a program. That program will turn into software. This software will then be used not just by you, but by your colleagues as well. And soon, it will be sold to a dozen customers. Your seed function of the first day, in a way, contained the “DNA” of the program that would grow out of it. Therefore, it makes sense to always write good code and refactor heavily along the way – even if you think you’re going to throw away the software eventually.

Truth: The manager will tell you that this software needs to be finished tomorrow, and that it will only go live for a week. After that, the software isn’t needed anymore, so you don’t need to take great care during implementation right now (considering that there’s no time anyway to do so, that’s good to hear).

Fiction: Self-explanatory code is also self-commenting. Given the choice between a comment and a piece of self-explanatory code, a good programmer will always prefer self-explanatory code. Some programmers even remove comments from code to fully understand it. Often, comments “lie” about the code – they may say X, which was true in 2001, but they didn’t get changed to Y, which is what happens in 2006. Temporary variables to avoid “magic numbers” and short, verbosely named functions aid readability better than many comments do.

Truth: The more comments you write, the better your software can be maintained. A large Word document saved far away from the actual running code helps as well. Temporary variables waste both storage and CPU cycles during execution of the code. The best programmer is the one using the most comments, end of story.

Fiction: Programming style is debatable, and such debates are often long and fruitless. Thus, a controversy erupting on coding conventions is not constructive. If there would be “one better way” to code, surely all the brains in the world would have come to an authoritative solution by now. Therefore, either go for one coding convention, agree that it’s arbitrary, and get on with work... or allow everyone to code in whatever style he or she feels is most appropriate.

Truth: Curly brackets must always go in the next line, and you must use tabs, not spaces.

Fiction: People can write good programs without multiple inheritance. Sometimes, OOP for the sake of OOP is just as silly as a 400 lines long function. The danger of “gold coating” a software is just as imminent as is the danger of quick’n’dirty throw-away approaches. A pragmatic programmer will use OOP, but never fall in love with the design of his own classes.

Truth: A complicated class structure only shows the programmer did a quality job. Inheritance is a necessary complexity, and simply can’t be overused.

Fiction: There’s a great many programming languages around. Often, the selected language was just cheaper to use, or pre-installed in your intranet, or the server, or it’s used because of its great library. While some languages are more elegant than others, that doesn’t really help your software much. A good programmer will know the pros and cons of many different programming languages and use whatever tool works best for the challenge at hand.

Truth: Real programmers use Java. No, make that Python. I mean C#. As long as it’s not PHP. Or anything that looks like BASIC.

Fiction: Today, there are many great web apps that were coded in prototype-ish, no variable declaration, try-as-you-go type of tools. These are programming languages but because of their high usability and behind-the-scenes compilation, they are called scripting languages. They are not better or worse, and the lines are often blurred.

Truth: There’s a huge difference between scripting languages and programming languages. Real programmers won’t touch a scripting language with a thirty foot pole, and rightfully so. If someone mentions that he uses X, a scripting language, he should be rightfully put down in front of others by pointing out the difference between scripting and programming (putting someone down is especially constructive in public newsgroups).

Fiction: A team discussing a lot and getting along great and programming a lot is more valuable than a verbose software specification.

Truth: “Getting along” is really too fuzzy and social to be part of any professional software development team. Actually, it’s about coding standards, keeping to the MS Project schedule, and not thinking too much outside of the box (as that endangers keeping to the schedule). In fact, with the right project plan you can put any random 5 programmers into the basement and shut the door close (and open up again when the deadline arrives), as long as you remember to feed them pizza.

Fiction: Programming is a craft; as such, it contains element of art as do other crafts. A creative programmer is creative enough to make synergies (e.g. graphics + code, or usability + software) work for her. A good work environment will not only facilitate these synergies, but demand them.

Truth: There is a need for strictly separated work groups, from management, to graphics, to concept, to writing content, to finally programming the whole thing. There are sub-categories here, e.g. Flash falls neatly into the “graphics” category (even ActionScript mainly moves graphics around). After all if a programmer was allowed to do a concept, he’ll end up choosing the simplest route to get from A to B without any of the glitz end users want to see. Truth is that programmers can’t draw, and artists can’t think logically. In fact, there is a certain danger of an artist thinking about software for longer stretches of time, as it effectively dries his inner well of creativity.

Fiction: Programming can be an interesting, adventurous, highly rewarding, creative, and fun thing to do. It should be taught in schools. People should be introduced to it at a young age, with a simple programming language. Not everyone will like it, but those who do will become incredibly great programmers who in the future will be creating incredibly great software.

Truth: Programming is for nerds! If you want to teach it, wait until 9th grade and use Java. Seriously.

Programming Truth and Fic ... by Philipp Lenssen | Comments (56)

>> More posts

Advertisement