Software Development Faux Pas

Software projects go bad sometimes. They are late to deliver, bad architecture, a lot of rework, cost overruns, etc. It’s rubbing salt in the wounds to say that this could have all been avoided, especially since the project still needs to be completed. People in charge of the project will never take responsibility for the reasons for the failure, but by Jove, they’ll still try to make it work. Because of differing agendas, the personnel that should have been put on the project, weren’t. Instead, newcomers were allowed to design and architect the solution. Why this happened is beyond me, as this company prizes its architects to a fault, and these newcomers were by no means architects.

The big flaw in trying to complete the project with the same architecture that caused the failure in delivering is that it’s a house of cards. The architecture is fragile, and will collapse at the slightest agitation. All throughout the design and development, the experienced people were hardly consulted. But would you like to guess who were called in the try and salvage the situation? You guessed it.

This scenario happens all the time in information technology departments all over the world. Perhaps the experienced people are taken for granted and it’s “better to be a flamboyant failure than any benign success”. Or perhaps the management feel that the experienced personnel are versed in “old” technology, and they need to “liven” things up with “new” and more functional technology. A lot of times, they fail to realize that the so-called “old” technology is the bread and butter of the company. In addition, when you use new and inexperienced people to architect a new solution for your system, the accrued knowledge of years of experience is not there, so the new people try to make up “stuff”, to disastrous consequences.

One of the reasons given for moving to new technologies and platforms, is that there are fewer people in the workforce versed in the “old” technology. That may be the case, but on the other hand, too many people versed in the “new” technology can be detrimental as well. When there are too many people clamoring to get “into” to the new technology, you get a case of developers that “are a dime a dozen” in this new technology. In other words, people in the old technology are more seasoned, while the new “enthusiasts” are still “green”, and couldn’t program themselves out of a paper bag.

The new technology has not really been proven to be better than the old technology. Sometimes the old technology is not really old. It’s just that it’s been around longer. What people may fail to realize is that if something’s been around longer, and kept up-to-date, it’s more robust than the “new” untried technology.

Anyway, this project is one for the historical records. What would be a pity, however, is that this experience will be forgotten, and bigger, more extensive projects in the future will follow the same path, to similar results.

This story is fictional and anyone mentioned in it are not intentionally depicted to reflect real life.

Posted in Uncategorized | Leave a comment

Why A Desktop App is better than a Web App (most of the time)

There is a common misconception that web applications are the way of the future, and the “way to go”. Most companies are convinced that moving their systems to web technologies like DotNet and Java Server Pages will ensure that they are not left with “old technology”. I, however, envision a future in which all applications are not web applications at all. Perhaps the science fiction writers missed the boat completely, but I don’t see any browser type applications in Star Trek or Star Wars. In all seriousness, the only advantages that web applications have over desktop applications are ease of installation and platform independence. In certain circumstances, these advantages can be diminished by the nature of the installation, and the availability of software tools that can generate desktop applications for multiple platforms.

If the web application will be deployed to multiple sites, just as it would for a desktop application, where is the advantage? The desktop application need only be installed on a server, and each client can access it via a shortcut.  Self-updating desktop applications can be developed if each executable needs to be on each client workstation.  Similarly, the web application will be deployed on the web server and the client machines access it via the browser. However, the deployment of web applications can be a messy affair. For one, there are many moving parts in a web application. First you have all those HTML, Javascript, Cascading Stylesheet, XML, and config files. In addition, if it’s a DotNet app, you also have ASPX and Dynamic Link Libraries (assemblies) – for Java apps, you have class and jar files. Even worse, if your web application uses a certain version of DotNet or Java Runtime, you have to deploy that version of DotNet or Java to be installed on the server.

The platform independence of Web Apps is greatly overrated.   Even within the same platform, web apps behave differently on different browsers.  So, instead of testing the application on the one platform, now you have to test it on multiple browsers on the one platform.  Then you have to test it on multiple browsers on other platforms.  If a cross-platform tool is used to develop your desktop application, it needs only be tested once for each platform.   This development tool should be able to generate binaries for different platforms with little or no change to the source code.

Web applications are more susceptible to security threats than desktop applications.  You can mitigate this by using Secured Socket Layer, but there’s not much you can do with the ability of the users looking at the source code of the HTML through the browser menus.  In addition, if you decide to hide the URL address bar from the users because you don’t want them typing something in there and thereby shooting themselves in the foot, the danger is even greater.  If you can’t see the URL of the website you are on, it is easier for malicious code to masquerade as your application.  Pop-up windows can also pose threats to web applications, as malicious code can masquerade as part of your program.  Desktop applications can use SSL for HTTP connections, and other means to encrypt data going across the wire.  In addition, it is extremely difficult to hack into the desktop application’s executable file.

Developing web applications is much more difficult than developing desktop applications.  Generally, web applications are stateless, which means that every time a web page is posted to the client, it’s lost all memory of what was done before.  Therefore, it is up to the web server application to maintain state or keep the state in the HTML code, in which case the HTML sent back to the client can be huge.   Managing this state of affairs (so to speak), gets complicated.   In addition, since data can only be displayed via HTML, web applications have to “emit” HTML, and it is difficult to display the data correctly this way.  There have been HTML code generators written to address this complexity, but it is nevertheless an issue.   Desktop applications, on the other hand, can be developed with RAD (rapid application development) tools such as Delphi and DotNet Winforms, in which the application has state, and does not rely on a server (in two-tiered systems) to manage state.   Using RAD, forms and windows can be easily created, even if MVC (module-view-controller) is used as a software pattern.

The performance of desktop applications is generally much better than web apps. This is because each web page has to be rendered by the browser, and it takes a longer time if more state is remembered between each push and get of the pages (when the HTML gets huge).  Also, in addition to the data that is being sent to and from the server, display elements are going across the wire, and so the amount of data going through the network is quadrupled.  Desktop applications, on the other hand, only sent data across the wire, since the display elements are already loaded in memory on the client machine.

Another advantage of a desktop application over a web application is that the desktop application can have access to all the resources of the client machine.  USB ports, printers, scanners, cameras, the file system, etc, can be utilized directly by desktop programs.  Web applications are at the mercy of the browser manufacturer and what they provide to the Javascript engine.   One of the reasons is because of the platform independent nature of web applications and security implications, so the browsers take a least common denominator approach.

In conclusion, I believe any complex computer system should be developed mainly as desktop applications, with auxiliary web applications for support where it makes sense.  It does not make sense to develop the whole system solely as web applications.  If a centralized solution is desired, this does not preclude desktop applications.  Desktop applications can access data and web services centrally via multiple tiers.

Posted in Uncategorized | Leave a comment

The Journey Begins

Hello there.    I have been a Delphi developer for the past 15 years.   I love the tool and the language.   However, I fell into a trap that I’ve only recently freed myself from.   I was so enamored with Delphi, that I refused to learn any other language and tool.   I had forgotten that being a software developer and programmer meant I could use any language to develop systems and solve problems, and the tool doesn’t matter.

How did I come to realize this?  Well, if Delphi were still alive and doing well, I probably would still be on the Delphi kick.   However, it is slowly dying on the vine, and other languages like C#, Java, Objective C, and Actionscript (Flex/Flash) are more prevalent. Delphi might have a revival with cross-platform and 64-bit features on the horizon.  Until then, however, it would behoove me to broaden my horizons and get some experience with other languages/environments.

The first language/environment that I will tackle is Visual Studio 2010 and C#.   I have done some ASP.Net development with Delphi 2005 – Delphi 2007, but in the Pascal language.   I have also taken a class in C# and played around with Visual Studio 2008, but I have not developed a real program.  I have some books that will introduce me to the language, and I have a project in mind that will involve ADO.Net access to SQL Server.  I will first write the applicate with ASP.Net, then WPF and then Silverlight (not sure if WPF and Silverlight are the same).

As I go along, I’ll post some tidbits about my experiences, and maybe some coding samples.

Posted in Uncategorized | 1 Comment