I recently saw two polar opposite recommendations; one from Jeff Atwood begging you to not write code; and one from Radovan Semančík suggesting that the only practical software to use is open source software that you can fix as needed.
Obviously Radovan’s approach is not a scalable one. While there are a lot of terrible software products out there, especially in the enterprise space, there are also a lot of good ones that just work. Limiting yourself to coding solutions is a waste of time that most companies won’t pay for. Also Radovan’s solution limits you to open source solutions implemented in a language you are familiar with.
At the same time there are some problems that just need a coding solution, or are best solved that way.
For enterprise solution I am going to thread the path between Jeff’s Scylla and Radovan’s Charybdis by posing these questions:
- How much coding should be expected to implement an enterprise solution?
- How can you find enterprise solutions the works well enough you don’t need the source code or extensive customizations?
An enterprise solution that requires you to write code or scripts to do basic functionality is not well designed, in my opinion. Coding or scripting should only be required wheen the functionality needed is unique to a specific deployment (or too uncommon enough to be a main feature of the product). This is a core philosophy at OptimalIdM as well. Although the VIS virtual directory does support .NET plug-ins, most of our customers never need one. When we have seen the need for plug-ins in the past we looked for a common feature that could be added to the product.
So not having to write code one measure an enterprise solution’s quality. Here are some others:
Ease of install – they say you only get one chance to make a good first impression and install time is it for enterprise software. If your vendor is telling you that you need consulting hours just to install the software, it’s not going to get better from there.
Ease of use – requiring training to use enterprise software is a bad sign. Did you have to have training to use your browser or word processor? Enterprise software should be like that.
Stability – once installed and configured the software should just work. Baby-sitting should not be required. And if you really need two weeks of work or the source code to figure out why your solution stopped working, you made a poor vendor choice.
So go ahead and write code, but only when you have to.
Johannes Ernst is predicting the demise of the RDBMS (and by extension Oracle) due to the growing popularity of NoSQL. While these kinds of technology trends are hard to predict, there is a lot of logic to what Johannes is saying. He could very well be proven prophetic.
But this is familiar ground. We have been here before.
I remember in the mid 90’s when Object Databases were going to kill the RDBMS. Of course what really happened was that Object-Relational-Mapping APIs became popular instead.
Later XML Databases were going to kill the RDBMS. Instead RDBMS vendors added native XML capabilities to their mainline products.
There are specific functional areas where RDBMSs have been displaced. For instance LDAP directories have mostly replaced RDBMSs for identity and authentication information. But this has not dented overall RDBMS usage.
So can NoSQL slay the RDBMS after OO and XML failed? Perhaps, but I wouldn’t short Oracle just yet.
Posted in AD, Authentication, Development, Identity, LDAP
Tagged Authentication, Identity, LDAP, NoSQL, Object Database, RDBMS, XML
Jeff Atwood has an interesting post on web programming vs traditional desktop development. But he goes way too far with this blanket statement:
Pretty soon, all programming will be web programming. If you don’t think that’s a cause for celebration for the average working programmer, then maybe you should find another profession.
All you say? Really?
Putting aside entire fields such as embedded systems, game development, database administration, mainframes, developer tools and compilers, network management, systems administration, configuration management, identity management, source code control systems, etc; one could say that “all end user application development will soon be web programming”. But even that is unlikely.
First of all the death of the desktop application a long way off. I have email accounts with Yahoo and Gmail, but both feed into my Thunderbird email desktop app. I only use the web interface when I am forced to use another computer. Word processing is still done predominantly on desktop apps. As is IM, media editing, and a host of over things that people do on a day to day basis.
Even a good portion of web development will soon be desktop development. Or put another way, instead of writing clunky web applications that at best approach what is possible on a desktop app, RIAs will be written in Silverlight, Flash, or JavaFX that deliver true desktop app functionality on the web.