Clarity in software development

My programming began with the use of Fortran and Watfive in high school on IBM mainframes. In University I learned Cobol, PL1, Pascal, APL and  C. Along the way I was exposed to assembler and machine language, both of which I used in both school and in my first few jobs. Attending the University of Waterloo Co-Op program afforded me the luxury of applying the skills learned in class to the workplace during work terms.  Learning in the process the practical use of the academic lessons.

Hollerith punch card

Writing programs on mainframe using punch cards

Read more of this post

eHealth the future depends on it

The recent scandal with eHealth Ontario has derailed the progress of electronic health records for the citizens of Ontario. Yet, if you look at the progress to date, since 2004 when the SSH (Smart Systems for Health) agency was formed the project hasn’t been much on track anyway.

Estimates are that between $600-700 million has been spent on the provincial initiatives for electronic health care. What did this funding produce? How did we get to his stage?
The challenge with any large complex undertaking is to divide up the complexity into manageable and deliverable chunks. This makes it easier to tackle the big problems. If you look at the entire problem and build a detailed, comprehensive and complete solution the time and effort it takes will erode the proposed outcome. By the time the analysis and design is approved the environment will have changed, and before building the brilliant and complex product, the solution will be obsolete no longer meeting the current needs.

Even when such complex, complicated systems are built and deployed they become unyielding and unmanageable. They are difficult to maintain and keep current with the ever changing needs of the situation.

There is a large movement in healthcare the favours a monolithic solution, one system that does all. This comes from an antiquated philosophy and those the promote this concept are very much “old-school”. The executives raised on the mainframe or single vendor concepts.

I have been an IT consultant for over 25 years and my experience began with mainframes, although at the same time I used key-punch cards to do my programming for high-school was also when the original Apple, TSR-80 and Pet Computers were introduced. My career is firmly in both camps.

Over time I’ve developed complex systems for the financial sector, manufacturing and service industry; initially on IBM Mainframes, then DEC mini-computers and eventual PCs. In the 1990 my work also evolved into “pen-computing”, wireless and mobile devices. The systems are increasingly more integrated and networked.

In my long career I have personally never seen a “single-source” ONE system solution be fully successful. The monolith approach only works for a short period of time, until new requirements or changes to the business environment requires modifications. Because of accelerated demand on business the monolithic solutions is left behind. Why? Because the time required to change these monolithic systems is often surpassed by new systems and product add-ons. Creating and maintaining monolithic solutions lead to ultimate failings.

Even where one vendor, single source solution in implemented, within a short period work-arounds and new systems will be introduced. Still there are “old school” executives wishing for the ONE solution. They want something simple to deal with in what is actually very complex problem.

The internet is one solution built on the simple idea of allowing documents to be shared regardless of platform used. You can view the internet using a PC, a MAC, Linux, Unix or any other type of computer. Regardless of operating system (OS) as long as you can run a browser you can view the web. To share documents all you need is a text editor to build a simple html page.

It wasn’t until 1996 that I built my first web-page; it was to announce my wedding. Later that year I was involved in creating a web-based software store called instamall.com. The concept was to use encrypted transaction processing to allow users to buy software on the web. It wasn’t very successful but it did point the way to the future of the internet.

Since that time the internet has grown to being more then just sharing documents. Dynamic applications and content have revolutionized how we interact with technology. The growth and acceptance of social networking has effectively changed the world.

The internet is a very large complex system. Yet, its strength is its open standards and architecture that allows many developers to create solutions to problems and develop tools we didn’t even know we needed. Who would have thought Facebook, a simple university student gossip and communication site would have 200 million users in less the 5 years?

Twitter

Twitter

What about Twitter an SMS message site that asked friends “What are you doing, now?” becoming a political force in the Iranian Election this year (2009)? By having open standards Facebook allowed developers to augment the site with new applications, effectively become a platform for new products that the Facebook staff could not have the time and resources to think about and develop themselves.

I’ve been using Twitter for 8 or 9 months now. Initially, it was novel using SMS to update my status. There wasn’t a lot of hype and only a few people followed my posts. Then suddenly hundreds began to link and follow my tweets. I now use Tweetdeck from my desktop and hootsuite to manage my accounts and Twitterberry on my Blackberry smartphone to send updates from where ever I am. Yet all these products were independently developed not by Twitter but independent developers using the open API provided by Twitter. Because of these a large adoption rate occurred in a short time. Because more the one company was building all the needs of the social users the adoption soared.

It is something to consider for eHealth solutions for a province like Ontario or the country of Canada or globally. Rather than build a monolithic ONE system to solve all the problems it is best to take a more modern approach. Use techniques common to the internet and social network sites; create an open platform to allow multiple developers to integrate and create innovative solutions to the problems of eHealth.

Another failing of ONE system approach is that each clinic, doctor, community and patient has different and unique needs. No matter how long and how detailed a single system envisaged it can never satisfy all the needs of all the users. The open architecture and open standards approach puts more people to work on the solution then could be every deployed and managed by ONE organization.

What is needed now is greater transparency and open specifications and standards can help accelerate the adoption and deployment of electronic healthcare.

Analysis Paralysis

In software development we have a term for spinning your wheels during the initial tentative phases of a project; Analysis paralysis occurs not because of lack of direction, the project is stuck because there are too many good ideas. Everyone has a solution to the problem and without a true strategic direction every one of these solutions can create a delay in the project outcome. Each avenue and opinion creates a path or possibility to consider before moving forward. The biggest problem with analysis paralysis is there is a lot of activity without much progress.

Traditional Waterfall Method

Traditional Waterfall Method

Traditional software development goes in a straight line with one phase leading into the next; Planning, Analysis, Design, Testing, Implementation. Also know as waterfall method this form of managing complex projects has all but been replaced by more agile methodologies.

 

Rapid development, early release with constant iteration is very successfully used by technology leaders such as Google.

iterative lifecycle

iterative lifecycle

It means putting out beta releases for review and consumer testing before the full product is fully materialized. For multi-faceted applications that require consensus from large and diverse user communities this approach allows for adjustments to be made frequently to satisfy more and more users.

 

Design, develop, deploy, and repeat. This is the way to move forward on large projects. http://www.firelily.com/opinions/cycle.html

Complex multi-year initiatives must be broken up into smaller projects each with manageable deliverables. Parsing large tasks into smaller manageable tasks makes it possible to advance. Small teams with decisive leaders make project results obtainable.

Breaking analysis paralysis can be done my taking on a simple part of the project and completing it, test it with real users. Review the results, gather observations and feedback and then move forward. Don`t waste time trying to document or design every possible contingency, take the project apart. Take each piece and produce it to the best of your capability now. Then review and revise.

Follow

Get every new post delivered to your Inbox.