Hoe moet het maken van software dan wel gezien worden? Voor een deel is software schrijven creatief, voor een ander deel wetenschappelijk-analytisch (scientific zouden Engelsen zeggen, helaas weet ik geen goede vertaling daarvoor). Als je het maken van software al zou willen vergelijken met bouwen van huizen, dan is dat alleen het maken van het ontwerp.
Wat een junior-programmer doet is vergelijkbaar met wat in de bouw ontwerpers van leiding en electriciteitssystemen in huizen doet. Wat een senior-programmer of architect doet, is vergelijkbaar met wat een (daadwerkelijke) architect doet of projectontwikkelaar.
Als je de metafoor van bouwen zou moeten vergelijken: De gemeente Utrecht had het idee een gigantische woontoren te bouwen: de Belle van Zuyden.

Een archtictbureau heeft een ontwerp gemaakt, een projectontwikkelaar heeft een schatting van de kosten gemaakt. Na een grondige test van het bouwontwerp en -plan, en een gebruikerstest, bleek het gebouw totaal niet werkbaar. Verder ontwerp is gestopt: intekenen van de verwarming is vermoedelijk niet gedaan.

Belle van Zuylen is niet daadwerkelijk gebouwd, ofwel het is nooit in productie gekomen.

Softwareontwikkeling is dus vergelijkbaar met ontwerpen van machines, gebouwen, en systemen in het algemeen, niet het bouwen zelf. Dat verzin ik niet ter plekke, dit wordt ook onderbouwd door meerdere mensen die er verstand van hebben. Collega’s hebben recentelijk nog een mooi artikel hierover geschreven:
Creativiteit in Software Ontwikkeling en Snel succesvolle projecten uitvoeren.

Goed boek om mee te beginnen:

The pattern (as you can call it) is very unlike webframeworks, where the software runs mostly on the server. When a user accesses a webapplication, the webframework will generate html, javascript and xml and send that to the client’s webbrowser. The webframework also needs to create a (HTTP-)session along with a sessionid that is stored at the client-computer.
When a client performs some interaction, like pressing a button, a relatively complicated process is started: a javascript event or browser submit is emitted. The webframework will retrieve that event on the server using generated javascript- and html-code. Using the sessionid, the right user-session, containing client-data is loaded after which more automagic processes are performed.
You might wonder, what about Ajax ? The answer, with Ajax, or JQuery or other framework, the only advantage is, in case o a UI-event not the entire browserpage has to be reloaded and shown on the user, but only a part.

Not so long ago most enterprise software was developed as client-server: a client application would run on an users computer, while the server would consist of a database server. The client would make a connection to the database. The (business) logic of the software was contained in the application, while the database contained the data.
This development-model was quite easy for developers. I don’t have hard data, but I think the productivy was much higher back then. My guess is that, for many simple CRUD-like requirements, a average Visual Basic, Delphy, Clipper developer was a lot faster.
Of course one of the mayor problems back then, were the installation and maintance of the client computers. Webapplications pretty much solved that, as the only client software you had was the browser.  Another problem is security: usually the client was connected with the server via a direct connection to the database. That means, if an unauthorized user would gain access to the client software he could do a lot of harm.
In webapplications, a user can only access the software by logging in the the webapplication. Without a username/passsword or other means of authentication, getting access to the server is very hard.

In modern RIA frameworks these problems are mostly solved. The software runs in a standardized plugin like the flash-player or java-player. That software is a lot easier to maintain then custom client software. A RIA-application accesses the server via a webservice. Fine-grained security can  added accessed to the webservice, preventing unauthorized access. That way, access to the server/backend can be controlled.

All in all, modern RIA bring back productivity to the developer and the user. Developers finally don’t have to waste time learning yet another greatest framework (Struts, SpringMVC, JSF, ADF, GWT), and solving problems inherently part of webdevelopment (http-sessions, javascript debugging, html hell, generated code) . Users finally don’t have to wast time waiting for browser refreshes, loading times and timewasting slow operations.

For an overview on different RIA-frameworks, and more on this subject see: Rich Internet Applications: State of the Union . The term design pattern for RIA I got from the following presentation of a Adobe Evangelist on J-Fall ’08.

• Encapsulate database access, using Data Access Objects so we’re not tied to one or another database
• Use Model View Controller pattern, so we can change the view logic easily without having to change the entire software.
• Use Facade beans and Remote Beans so we can separate our application server in a frontend-server and business-logic server.
• Know the book of GoF by heart and use their patterns, so our code is good.

However that’s all wrong! The principles are good, when applied correctly. However the reasons are all wrong resulting mediocre software. If in any project changing database is from for example from MySQL to Oracle or changing view-layer from JSF to GWT is a possibility, then that software-project is very bad managed. The ability to change a product shouldn’t be the reason. And if people think they can have their software be more robust are perform better by setting up an extra business-logic server, they’ll be disappointed.

Because people often use the wrong reasons, a lot of code is overly complicated, badly performing and highly unmaintainable. You known something is wrong if you have to wade to a lot of interfaces, Impl classes, XML-configuration files just to known what a piece of code is doing

Naturally the principles are good, however, the goal is totally different.  The reason for all of the principles should be: program correctly functioning code that can be adapted easily now or in the future.
Design patterns isn’t a bible

Known that any book on design patters shouldn’t be used as a bible. Wrongly applied design patterns produce terrible code. The book of GoF was a great book because they (Gamma et al.) introduced the concept of design patterns and gave a list of good design patterns for C++ and Smalltalk. Many of the design patterns are relevant, but many are also not.

Design Patterns
Erich Gamma & Craig Larman

Most important contribution of the book, is the notion of design patterns. They introduces common words, a name, like Data Access Object, Visitor, Singleton to programming constructs. Because they gave name to certain programmings patterns, people can talk about them and understand each others code. Similar like architects use various patterns to design houses, office buildings, public buildings or monuments. The origin of design patterns was a book about architecture:

The Timeless Way of Building
Christopher Alexander

There are endless design patterns besides the one listed in Design Patterns: Elements of Reusable design. Every programming language, framework and software project and application has its own patterns. Recognize patterns, give them a name if they haven’t got one. Make sure the patterns and the naming are known within the company, organization or all of the users of a framework. That way, the code will be easily to grasp for anyone who has modify or extend the software, because of common naming and usage.

Great coder

Read who a  great hacker is, how to become better programmer read what you can do to be a better coder. The greatest cause why software development is so expensive and costly, is because there’s enough emphasis within many organisations on writing good code.