wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

Enemy of the <strike>state</strike> IT system #1 : complexity


As the saying goes the complexity of any system grows at the square of the components involved. We do live in a complex world, so you can shrug, surrender to the unavoidable and move on. Or you can take a closer look and discover differences in complexity. There is the complexity from the nature of the task at hand and there is the complexity we add in the way we approach the completion of the task. Order a meal in a restaurant can be straight forward or incredibly complex. You can call that " Essential Complexity" and " Accidental Complexity", terms coined by Fred Brooks over 20 years ago. His book The Mythical Man-Month is a must read for any software engineer or normal mortal human dealing with software engineers. Brooks states that software isn't werewolfs, so there is no silver bullet. While I fully agree with his insights, I more and more doubt, that the second complexity is really " accidental". It is man made and IMHO quite deliberate. Of course we never need to assume malice where incompetence is sufficient to explain*. Let us look at the setup of your average web application (and I skipped the provisioning and monitoring pieces, as well as the diverse interfaces to administrate all this):
Too many moving parts
After careful counting that would make 6 servers or a complexity of 36. The setup is typical for Microsoft setups (Exchange, ActiveDir, Sharepoint, IIS, DotNet, SQL Server) as well as for Java setups (Apache HTTP, Tomcat/WAS, Samba, LDAP, DB2/MySQL, POP/IMAP) or your favourite scripting environment (just swap out Tomcat/WAS for the script of your choice). Not all of these servers need to be physical boxes or virtual images. They can be tasks running on one hardware. Make that high available (12 boxes) and you have a complexity of 144. Of course you could use Domino for your applications. The setup will look like this:
DominoSimplicity.png
Of course to get there you have to challenge your believes:
  • Complexity is good
  • Web systems need to be 3 tier
  • A directory must be dedicated LDAP (Domino does LDAP, as does AD)
  • Databases must be relational
  • Only complex setups scale
  • Only with [insert-your-favourite-language-here] web applications can be developed properly
  • And then the Lotus Domino specific ones:
    • Domino is legacy
    • Domino doesn't scale
    • NSF is not reliable
    • Web development with Domino is complicated
* On the other hand: Any sufficiently advanced incompetence is indistinguishable from malice.

Posted by on 10 April 2009 | Comments (8) | categories: Show-N-Tell Thursday

Comments

  1. posted by Carl Tyler on Friday 10 April 2009 AD:
    Ah the good old days. Sadly if you start adding Sametime, Sametime gateway, Sametime Advanced, Quickr, Connections etc. your Domino picture looks a lot like the first one.

    Domino is the perfect server for SMB, IBM may be starting to realise that with Foundations. I hope work gets done again to allow Sametime, Domino and Quickr to run on the same box (without having to use VMware)
  2. posted by Jonathan Wong on Sunday 12 April 2009 AD:
    "Only with [insert-your-favourite-language-here] web applications can be developed properly"

    Actually, with the right resource with the proper skills, any language can be used to develop web applications properly.

    So the key point here is "skills".

    If you are developing a web app and you have considerations such as future maintainability and availability of skilled resources - would you rather do it in a language like ASP.NET, Java, or PHP, with gazillions of developers and books and other resources, or do it in XPages/LotusScript with only maybe 30 skilled people in a country (from attending a workshop)? Emoticon tongue.gif
  3. posted by Nathan T. Freeman on Sunday 12 April 2009 AD:
    "Any sufficiently advanced incompetence is indistinguishable from malice."

    A priceless adaptation of a marvelous quote. Emoticon smile.gif
  4. posted by Stephan H. Wissel on Monday 13 April 2009 AD:
    @Jonathan, nice try:
    3 flaws in your argument:
    - Sticking to "what is there" would make use write software in Cobol, Fortran and Assembler till today. There was a time where PHP, Ruby, C# were all new.
    - Quantity of developers isn't Quality.
    - XPages applications are written in Javascript (not LotusScript), the most pervasive language of all. It draws execution power from a solid JSF foundation without exposing the complexity. Using XPages you have a single language, JavaScript, while in ASP, JSP, PHP, Ruby, CGI etc. you have different languages for front-end and back-end. And we all know know much more difficult language soup is to maintain.
    Emoticon smile.gif stw
  5. posted by Mr Ports on Monday 13 April 2009 AD:
    @Carl - I have ST, Quickr and Domino all running together on one box (my demo Thinkpad). All works fine (though not officially supported)
  6. posted by Edward on Thursday 17 December 2009 AD:
    you know at first I was surprised (and quite amused:) to see this tutorial in pictures. it reminded me some manuals kids always get while trying to cope with a toy or lego. but then I realized that actually it's the same: we just use toys for adults. thank you for sharing this! everything is simple.
  7. posted by rapidshare downloads on Thursday 09 September 2010 AD:
    you are developing a web app and you have considerations such as future maintainability and availability of skilled resources - would you rather do it in a language like ASP.NET, Java, or PHP, with gazillions of developers and books and other resources, or do it in XPages
  8. posted by James on Tuesday 28 September 2010 AD:
    I think that people have an unbelievable level of arrogance when it comes to dealing with complexity. I suspect that our brains tend to simplify the reality of the situation as a coping mechanism. The consequences are that overly complex solutions tend to be put in place which then need management + maintenance. Nice post.