Hats-off!

I am always fascinated by the success of human spirit and effort! Hats-off to A R Rahman and Rasool Pookutty for their winning Oscar awards.

I salute Hollywood for their open mind, true to the American spirit that has always stood for, and accepted, what is good from world over. I respect that American spirit, and I believe that to be instrumental to the success that America has seen in the past.

Going forward, I hope that openness prevails in the long run, despite the temporary gloom set by the economic recession. I believe there is a lot that a country and civilisation that gave the world the word that precedes silence and is followed by more silence would contribute towards world at large

Software architecture

Following are my comments on “if in Building construction Architect requried then why not in Software development?” in International Association of Software Architects group in Linkedin

Great to see an healthy progress of discussion.

I agree with much of views expressed above:
1. Business planning role as a Technical role: Yes, Software is intended to serve a business purpose, and therefore, architect has to balance between business and technical perspectives
2. In constructing a typical 1-storey brick house, you wont need an architect, but not true for a complex of mixed-use structures: Yes, trivial constructions doenot require an architect (though it requires someone to know and decide that what is being constructed is trivial). However, when trivial construction go on to serve larger business cause, that would call for an architect (depending on size and nature of work-involved) to decide whether that could be achieved. It is yet another matter, whether these decisions are made by someone designated as xyzArchitect or by someone who plays that role as an overloaded function
3. Foresight matters: Yes, architect should have foresight (and use as much techniques to enhance it as well) as much as humanly possible
4. Frequent changes in requirements: Yes, Architect has to work with frequent changes in requirements, and decide what should be done from the list of what can done
5. Cares about the quality, and who has a broad vision: Yes, architect should care about quality as product is serving a business and social purpose
6. Ability, knowledge and expertise to go through all phases of SDLC: Yes, to be effective, architect should have knowledge and expertise in all phases of SDLC to balance interests which are, at times, in conflict with some others
7. A Software architect is NOT a Deity or any other form of holy entity to be worshiped: Yes, software architect is a role accountable to business. Again, software architect is not infallible, and can only try and balance the conflicting interests powered by his skills, knowledge and experience
8. Old and time-valued profession when it comes to construction: Yes, we are young as industry but it is great that we have explicitly realized the importance of architecture early on. That should give us late entrant advantage of learning from others
9. We have not had enough amount of accumulated software mistakes: I believe, being pervasive (meaning that software is everywhere and influencing every business/life), it is very important that we initiate task of accumulating software mistakes and learning from such mistakes.

Software development and Scientific quest

I am a software engineer. By that I mean that I try to adapt and apply engineering principles and practices to software development.

I have been in software development in various roles, over 24 years now. I have been:
A programmer: I have programmed in FORTRAN, COBOL, BASIC, Perl, C, C++, and Java
A tester: I have tested (manually and with tool) wide variety of applications including enterprise applications involving SAP, J2EE, .Net, etc as well as embedded applications
A business analyst: I have worked with customers to give them software solution that meet their business needs
A manager: I have worked with customers and my team to deliver solution to my customer

All along my career, I was also looking software development practice from a scientific perspective. I am concerned ….

What I am concerned is, many new initiatives which are proven to be successful still remain in the realm of hypothesis rather than of a proven theory.

For instance, I have been using object oriented approach since early 90s and I am personally convinced and successful on that. Object oriented approach dates back to 70s, with significant academic and research background. I am yet to see a convincing statement uncolored by vested interests that a scientific community would require.

Practising what we preach!

We, as software professionals, take pride in enabling business of our customers. We help by automating their business processes and providing information on fingertips, across geographical, cultural and language barriers! We help automate because it helps our customers in their core work, leaving the mundane part to the machine

Let us, for a moment, reflect on our business! How much of our daily work is mundane and how much is creative? Are we not caught up in application silos and information islands? More specifically, is not our information split and redundant across word processors (requirements), modeling tools (design), testing tools, project management tools etc? What happens to crucial project, design, coding and testing decisions made in numerous meetings and information discussions?

Is not time we automate our business like we have automated other businesses? Or, have we automated enough so that we can focus on creative? I am not referring to use of tools here but rather I am referring to automation which might need the use of tools. I am making the distinction because we get caught into limitations/idiosyncrasies of tools, rather than attempting automating the way as much as we want.

Business demand that we deliver better quality faster, and that cannot be achieved by reducing “head count” alone. It can only be done by making heads more focused and productive. Again, it cannot be achieved by buying commercial tools and “implementing” them.

World has thrown up a challenge and opportunity in the form of recession. I believe, as individuals and organizations, it is important to seize the opportunity and surge ahead during this tough times to stay counted tomorrow. I believe, engineering and automation as the way out with values and principles of agile manifesto as guiding light.

What am I suggesting? Have we not seen the same situation with our customers? Have not bridged their silos? I am suggesting that we know the solution and we have the solution. We have extended the solution for others, and now we need to reflect on our work and do it ourselves.

It is time to practice what we preach!

Some observations on software testing and test automation practices

Following are my comments on “What do you think about the future of Software Testing?” in International Association of Software Architects group in Linkedin

Software testing was undervalued but no longer. Yes, there are people who undervalue software testing .

There is a tendency to overlook important of testing in immature software development environments. This typically happens in organizations or projects in a reactive (or worse, firefighting) mode. Immediacy of business imperatives in such cases being to churn out code (as if quality is of someone else’s concern….. An interesting thought in this line http://www.ibm.com/developerworks/rational/library/2800.html ).

Testing is an integral part of any development activity, and hence an integral part of software development as well.

Test driven development is a great way forward, it brings focus on testing quite upfront and makes it almost inescapable

I agree with the bottom line from Stephen with a minor refinement: Adherence to craftsmanship and good coding practices, plus the use of a good automation tool. I would also like to add agile values and principles to the list.

Refinement being “good automation” rather than “good automation tool”. What we need is automation, and tool is incidental. Purpose could also be served by in-house automation effort. In-house automation could also result in a tool. I am making refinement as purchase of tool generally comes with expectation of a “silver bullet”

Testing Alone Doesn’t Guarantee Quality

Following are my comments on “The Application Quality Dilemma: Why Testing Alone Doesn’t Guarantee Quality?” in Software Testing & Quality Assurance group in Linkedin

A good quality software cannot be produced by processes and tools; it can only be done by people. Hence, software development is essentially a teamwork.

Process, standards, methodologies, best practices and tools are only enablers.
—————————————————————-
It is naive to assume that testing alone can guarantee quality software. After all, examinations alone does not make a great student come out of school/college!

Testing is essential but one of the many such essential activities that goes into making a quality product; not just software.

I agree with above statements:
Testing is a function that the business cannot do without

It is important by the companies to acknowledge that testing is a critical part of the SDLC… that should be done with clearly defined responsibility, authority, resouces and ownership

Test tools alone does not guarantee anything other than a cost to the company… I agree that vendors have contributed to the testing tools but I believe unrealistic expectations are also part of the problem…

This is something I had been working with over more than 7 years now and, hence, close to my heart:

* Expectations, misunderstandings and disappointments related to test automation is common in many first time automation efforts. Actual upfront effort involved is hardly realized upfront by novices

* Tool is only a means for an end; end being test automation which in turn is for better productivity (sometimes misinterpreted as elimination of human effort), repeatability, predictability and control

* One of the first tasks in my test automation assignments has been setting the expectations right

* What is being automated is testing, and not test development

* Just as a development environment helps a programmer in development of program (but does not develop program replacing programmer), testing tool can help a tester develop test (does not develop test replacing tester)

* I have not seen any test automation (or any automation project, for that matter) successful without setting the expectations upfront

Tailpiece: A typical (read “failed”) test automation project reminds me of a machine to help men eat in the Charlie Chaplin movie “modern times”… We seem to have invented a software equivalent in test automation