Though, I am quite busy with new product development nowadays at client site; feeling compelled share with you these quotes I came across recently.
"Programmers are in a race with the Universe to create bigger and better idiot-proof programs, while the Universe is trying to create bigger and better idiots. So far the Universe is winning." - Anon
"If debugging is the process of removing bugs, then programming must be the process
of putting them in." - Edsger Dijkstra
Well even though there are less examples of bug free software; we see around many softwares/systems which have outlived their lives and ages. These systems are still in use and popular and of course most of them are bunch robust software components or product of some ingenious designs. I guess we all strive to build such systems.
So how to build bug-free, stable, usable and successful software?
What is it that is lacking to achieve this - skills, technology, process, discipline or all of them in different percentages.
I guess there are many theories, articles, journals, and books addressing best practices.
@ the risk of sounding boastful (very very very rare moment for me)
After having created many stable software components, I have realized that the first step to better systems is to create a precise and clear "vision" and communicate it across all stakeholders. Without it in the first place things are more likely to go haywire ultimately. So if you are starting upon some new development, just say to yourself the line below and rest of things shall begin fall in place.
"I'm gonna create a robust, stable, usable, precise and efficient system".
Sounds simplistically simple? How tough can it be to begin with this line?
I have seen many good people starting with "I'm just gonna get it done".
It reminds me again of another quote by the famous author
“If you don't know where you are going, any road will get you there.” - Lewis Caroll
Inside a very well written large program resides a very well written small program. - C.A.R. Hoare (author of quicksort)
)We need to understand exactly what "flexibility" is being discussed here.
Flexibility in System? or Flexibility to accomodate changing requirements?
If it is former - it has no importance by itself. Ultimately any flexibility in system is supposed to meet some requirement.
If it is latter only thing an architect can do is to anticipate extensions/changes in business needs/future requirements so as to organize the system into components/layers is such a manner that it is easier to accomodate changes.
[What is the benefit of modularity and division of responsibility if not this?]
Ideal thing is to expect requirements never change, but we all know how things are in practice.
"Expect the best but plan for worse".
I hope this helps.
(Much appreciated response to the question posted on linkedin
Visit thecloudapp.com to know more. The contest has 2 categories ASP.NET & PHP based cloud applications. It was to promote Windows Azure Cloud Computing platform of Microsoft.
"Cloud Computing" is a new area where a war is about to be broken between major players encouraging users onto Infrastructure as a Service(IaaS) bandwagon. Amazon cloud which offers storage, computing and other services is probably the most heard of. Many players have already started offering cloud based infrastructure and development frameworks like Google Apps, Force.com, Rackspace Cloud Hosting and many others. Microsoft has come up with Windows Azure as cloud hosted on its infrastructure.
Success of cloud computing particularly azure is possible only if it shall deliver significantly on attributes like simplicity, familiarity and cost.
Familiarity? Most of all it seems to have achieved familiarity as developers in .NET area can quickly ramp up to the cloud. Google lacks this in its cloud initiative as its has stuck to python as development language and framework and has recently launched a beta of Java, which make developing web AJAX + cloud based applications a breeze with the standard Eclipse IDE.
Simplicity? Atleast the development environment requirements are not simple setting up development environment can take long time - downloading and installing various components. No single installer there! Microsoft installer technology is not elegant and speedy but its a separate topic.
Cost ? It remains to be seen.
One may sign up for Community Technology Preview (CTP) of Microsoft Azure at www.azure.com. I tried building a simple application in C#/ASP.NET.
Recently read a book "Large Scale Software Architecture - A practical guide to using UML." After a long time found a book which is very precise, practical and to the point; especially the details about the architecture view points. Authors Jeff Garland and Richard Anthony have done a splendid job.
I believe that language and technology are the barriers which architects create for themselves. A open mind can solve problem faster, easier and cheaper.
Who would have thought a generation of scripting / web scripting languages like python and perl could automate your tasks, parse xml and html, handle interupts, run periodic programs, provide regular expression and scripting engines to your programs.
Architect should break the language barrier and select something most suitable for the task. If a task demands something to be done by multiple languages so be it.
Recently devising localization architecture for client user interface (web pages) the need for parsing HTML arose. Optimal solution led to "python" (a programming language - to those uninitiated) which can make the task achievable in few hundred lines of code. Most importantly I could find that the HTML parser was in-built and sample code available to use.
This is a huge dilemma.
But according to me the ultimately choice is an architect who
- understands concerns of various stakeholders
- practical implementation approach rather than theoretical (rare breed)
- focuses on quality right from word go (hence saves costs!)
- technology passion is required but with emotional detachment. [it is this which spoils the game]
- must believe in processes and following them
I think these qualities can get any job done good enough!!!
Hope this helps,
(This is my answer to question posted on IASA Group on Linked In - http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1523&discussionID=7285433&sik=1253305771360&split_page=1&report.success=PdmtybENV2mnc3t3p8JpWuFiB1ZhaD9OnKUphCsu7LRNRYTOK1wrHHO_rcDN0rVBb1wuxUyPL-SZ)
The first priority should be communicating with stakeholders about the need for retiring the solution and replacements available.
I think the most resistance would be from marketing/sales and customer teams who have already become well used to the system and are in a comfort zone. Not to mention the development teams worries about their role.
Next step becomes easier if we demonstrate a viable alternative modern system which allows easy phase by phase replacement of legacy system. A pilot project with willing internal/external customer can help top management and other stakeholder see the advantages.
But when replacing system entirely one should never discount the possibility redesign/re-eengineering some components can help us avoid complete overhaul when really not required.
Also important is to consider how much investments have gone in to the system and what is legacy. Do call a 2 year old system or 5 yr old or 10 yr old system as legacy???? I think that's a call which can be specific to the legacy under consideration.
Hope this helps,
(Excerpt from my suggestion on IASA-Linkedin Discussion