Software Engineer’s Blog

Software Engineering weblog

Measuring agile project manager’s success

Following are my comments on discussion “What’s a good measure of an Agile project manager’s success?” in ‘Agile CMMI’ group in Linkedin

I had been with agile approach all along, enamored by the simplicity. Do we need to complicate?

I like it because it has brought trust and communication back into our business which was lost into documentation in the name process. To me, our job is to deliver value to our customer on time and budget.

What am I going to do measuring my project manager whom I trust? What is the point in finding out that he/she measure up or does not? We are delivering or we are not. If we are not, we need to find that out ASAP and make amends.

Let us measure project (not project manager) and help project manager

Advertisements

August 27, 2009 Posted by | Agile, software engineering, Software Quality | Leave a comment

A Magazine on Software Test Automation

Though software test automation has been around for quite some time by now, success with test automation is far and few. Test automation space is replete with marketing hype, technical jargon, and claims of “silver bullet” solutions. Adding to the woes are idiosyncrasies of test automation tools used. Scene is sufficiently confusing to an innocent but curiously enticing to the gullible.

In my experience, failures are partly due to i) expectations based on hype rather than facts from the field, ii) half-hearted but expensive approach to automation as an extension of manual testing and iii) lack of business focus. These are, by no means, unique to software test automation; we have seen this repeated many times over in the past

I think, it is time for the dust to settle with increased demand for quality in software. I have come across a magazine focused exclusively on automated testing.

I am glad to see such an effort; it is need of the hour. I hope this magazine would help in harvesting success patterns, promoting knowledge exchange, scientific spirit and objective analysis in test automation space.

August 27, 2009 Posted by | Functional testing, Software Quality, Software Testing, Test automation, Test Automation Architecture, Test Automation Framework, Testing | Leave a comment

Consortium for IT Software Quality

As software permeates every aspect of daily life and as we depend more and more on software in all walks of life, quality of software gets to be of utmost importance.

World has come a long way from the early perceptions of quality as a natural consequence of following a good process. Agile community has asserted umpteen times, reflecting in manifesto of software craftsmanship and agile manifesto, quality of software that add value to users in their context is far more importance than religious, and often dogmatic, adherence to process.

People, process and automation are three different, orthogonal but often inseparably interrelated, factors of what goes into making of a quality software. These form different dimensions that call for attention of a manager of software development project, and not conflicting goals as they are sometime made out to be. Managing software development project is not progressing on one dimension at the cost of another but working with a dynamic balancing of these dimensions through the course of project

Three dimensions of software quality

Three dimensions of software quality

It is interesting to note, in this context, emergence of a consortium focused on software quality. It is a step in the right direction. I hope that this would help in making life better for its users and customers

August 20, 2009 Posted by | Agile, Product Engineering, Software architecture, software engineering, Software Factory, Software Quality, Software Testing, Testing, Uncategorized, Unified Process | 1 Comment

Art, Craft, Science or Engineering?

There have been many discussions in the past on whether software development is an art, craft, science or engineering. For convenience, I am listing below the major ones that had profound influence on my thoughts over years

1. Book Software Craftsmanship – The New Imperative
2. From Craft to Science Part 1 and Part 2
3. The great art and craft of software development
4. Software engineering and the Art of Design
5. The art, science and engineering of software development
6. Manifesto of software craftsmanship
7. The privilege and responsibility of software development
8. Commitment
9. What is software design?
10. Software that lasts 200 years

My view is that software development is a combination of all of above. My view is also that software is a construction of human mind or rather minds; and should I say human brains. Yes, mind and brain. Emotion and intellect. What is important to me is this human creation has pervaded virtually every aspect of life and business by now, unlike any other human creation, and hence business critical.

It is an art, it is a craft… beyond all that business depends on it; life and career of many depends on it. Hence, it is important to bring in continually better control, better quality, better transparency and better predictability into software development. Taking recourse to engineering is to this end. Engineering is not an end in itself but a means to an end. Engineering as a manager’s tool to have better control, better quality, better transparency and better predictability. From that standpoint, we find that apparently conflicting perspectives are not truly conflicting; they are different dimensions of software development.

Every successful software development manager knows this and manages his/her business accordingly. These fits into my overall management-engineering framework; result of applying learning into practice, and continually refining my learning based on observation.

August 14, 2009 Posted by | Agile, Product Engineering, Rational, Rational Unified Process, software engineering, Software Factory, Software Quality, Uncategorized, Unified Process | Leave a comment

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”

February 4, 2009 Posted by | Agile, Agile testing, Software Quality, Software Testing, Test automation, Testing | Leave a comment

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

 

February 4, 2009 Posted by | software engineering, Software Quality, Software Testing, Testing, Uncategorized | Leave a comment

What’s your opinion? Which is best? RUP, Scrum, or XP?

Following are my comments on “What’s your opinion? Which is best? RUP, Scrum, or XP?” in Agile Alliance group in Linkedin

First comment:
Why not RUP and …? RUP is a process framework/knowledge base and not a prescriptive process. You rather use RUP to derive a process instance

Subsequent comment:
Great to see the active and healthy discussion and hope to see this progressing further.

In this context, I would like to reiterate and substantiate my statement that RUP is not a process but rather a knowledge base and process framework. Lists of activities, relative order in which they should be performed, which artifacts to create, and dependency between them are more of guidelines/reference, and not meant to be prescriptions. Interesting links to read in this line would be: http://www.agilealliance.org/system/article/file/941/file.pdf and http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan03/StoryOfRUPManager_TheRationalEdge_Jan2003.pdf . There are many more but I hope these links clarifies

One does not adopt knowledge base and process framework. Rather, you pick and choose from it. I agree, “extract any element of RUP you think you need on a given project and add it to Scrum”, as pointed out by Richard, is the right way to use it. Meaning, in that case you are using RUP as a reference, and not as a textbook or bible. Again, you need not worry about size of encyclopedia if you know what you need from that

Again, I believe, good architecture and design is important for software development and role of architect, for me, is in war front (and therefor, hands on and continuous; again in sync with RUP), and not in the control room. Such architecturally-orientation is not in conflict with agile practices. In my understanding, what agile practices stand for is ‘right sized” architecture or design, rather than discounting their value.

Incidentally, I do not ask my customers to adopt RUP but I present to them as a knowledge base only. I also use it as a knowledge base, at the back of my mind, in my consulting service.

I would like to hear from you on your thoughts and on what you find in as conflicting

January 20, 2009 Posted by | Agile, IBM Rational, Product Engineering, Rational, Rational Unified Process, software engineering, Software Quality, Uncategorized, Unified Process | Leave a comment

A retrospection!

Looking back, last two years have been personally very taxing. Specifically, 2007 was traumatic personally. Though some of the traumatic experience continued into 2008, it was more of recovery personally and a time for change and consolidation Professionally. And, it was a mixed bag from the world around me.

World around me:
Chandrayan and India’s achievements in Beijing Olympics after a long while are on top of my mind on a positive note. Yet another unforgettable development is a Sister Alphonsa reaching sainthood. Happiness of these, however, marred to some extent by Mumbai bomb attack and global economic recession.

Personal:
My cousin Jayan Varma became world’s fastest percussive bassist. On the negative, my father’s health suffered serious jolt. By god’s grace, timely intervention and good medical care, he has recovered to a great extent. May be unrealistic to expect at his old age but, as a son, I expected him to be ever active. Now, he along with my mother require constant attention. I am yet to figure out what best I can do for them.

2008 was also a year when I could connect back many of my old friends. Sunil, Ashok, Suresh, Romy, and Narayanan from my college days, and my friends Arun, Unnikrishnan, Madhavan, Zacharia, Varughese and Vaideeswaran from days of my first job. I could also connect to Amit and Shanmugham from CMC Ltd, Hyderabad.

This was also a year when Mr. Naresh Kumar Reddy passed away. I was shocked to hear that sad news. I was reporting to him during later part of my tenure at CMC Ltd. I learned quite a bit of management lessons working with him. Time has to say how effective I was in their application. Pray to God that his soul may rest in peace.

Professional:
On professional front, in 2008, I have worked closely with Vikram Sarabhai Space Center, Trivandrum (Ministry of Defence, Government of India), and Weapons and Electronics Systems Engineering Establishment (Ministry of Defence, Government of India), Delhi helping them adopt software engineering best practices, methodologies and tools. As a departure from the past, I had started traveling outside India on business, with a visit to Qatar in October 2007. This was followed by visit to Saudi Arabia in March-April 2008 and a visit to Nigeria in June-July 2008. In the meantime, I was working for a customer in Germany remotely from India for test automation of SAP implementation. I visited Germany, by November 2008, to commence yet another project on test automation of SAP implementation.

Overall, I am happy looking back as indicated in old farewell note to Rational that I had written in 2002, having achieved what I had set out to.

My professional high in 2008 were:
1. Publishing case studies of success from India, a result of hard work in the past
2. Paper presentation at Rational Software Development Conference in Munich, Germany
3. Publishing case studies of success in test automation of SAP implementation in Germany
4. Release of Ready for IBM Rational Software plug-in Astra Model Creator and Astra Test Automat, with best practice compliance

2008 was also a year when I could connect back many of my old friends. Sunil, Ashok, Suresh, Romy, and Narayanan from my college days, and my friends Arun, Unnikrishnan, Madhavan, Zacharia, Varughese and Vaideeswaran from days of my first job.

I shall write on what I look forward to in 2009 and further in my note tomorrow

My favorite song for the year 2008 reflection (movie: Aap Ki Kasam):

December 31, 2008 Posted by | software engineering, Software Quality, Testing, Uncategorized | Leave a comment

Further on software testing paradox

Taking discussion on software testing paradox further:
Thanks for the active discussion on the topic. I appreciate the view points expressed here.

One common thread that runs through all comments being the developer himself is doing/expected to do quite a bit of testing of what he makes. I find that common thread also running through the earlier quoted article Commitment, The privilege and responsibility of software development, Test Driven Development and also in the code of ethics for software engineering published by IEEE.

Spirit is the same but when it comes to practice, naturally, business and commercial priorities take over and focus is primarily on delivery of code.

I have no intention to deride developers, or any other stakeholders. I do my bit of coding these days as well, and I do test, I manage projects and I manage customers. As a manager, I trust my team and my experience is that team delivers best in high trust environment. As a developer, I would not (I believe, no professional would) like to have bugs in the software. (After all, it is my baby; why should that be inferior?) Again, business/commercial considerations are not bad; the very reason for we being where we are. If my manager is expecting something out of me, or my team, it is for a good reason

I agree with statements of conventional wisdom: Developer needs to test their code. Testing needs to be done at the unit, integration, system and user acceptance levels. Defects discovered earlier the cheaper and the better. Testing needs to check that software does what it is supposed to do and also check that software does not do what it is not supposed to do.

With current year is coming to an end, getting into new year with a lot of expectation, a hope for a better tomorrow, I would like to ponder on ‘can our life be better?’; hopefully, the right time to spare a little thought, spend a little time on seventh habit (“Sharpen the saw”) of ‘The Seven Habits of Highly Effective People’? After all, if we do more or less the same thing, it is natural that we get more or less the same results. Can we do something different to retain/increase productivity and quality without increasing cost? That could help us when purse strings are tight

December 29, 2008 Posted by | software engineering, Software Quality, Software Testing, Testing, Uncategorized | Leave a comment

Software development paradox

We have helped our customers/users automate their business processes. We have integrated islands of information in their business. We save them from deluge of data cutting across organizational structures and geographical barriers. We have indeed transformed the society

Is it not time to reflect on our own business? How much have we done? I am not referring to documenting requirements, design etc in electronic format using word processors, requirements and design tools, etc. What we do for our customers/users definitely go beyond this. How much have we automated our business processes? If we have, have we done enough? What are the barriers in progressing further?

I believe, now is a right time to introspect as we take a pause and look forward to a new beginning

Watch discussion on this, in Software Professionals group in Linkedin

December 27, 2008 Posted by | Product Engineering, software engineering, Software Quality | Leave a comment