These days I am in Doha, Qatar for deployment of a check book printing solution. It's an exciting project with a good mix of technologies: an NCR kiosk with touch screen display, a Rototype CBD1000 machine that will print checks and bind them together; integration with the backend systems (MS SOAP Toolkit 3.0 and Oracle stored procedures) and the best part is that it's bilingual - English and Arabic - what else would one desire?
(As a side note, my company, Avanza Solutions, is better than its competitor in many ways; the most important difference is our aggressive nature. They being older in the market are now mostly supporting their products only. We, on the other hand, are open to changes/ enhancements in our products.)
If you ask me what is the most difficult part of software life cycle, I would say, "Going Live!" Somehow, software deployment takes as much time as development. Ideally one would like to have one button to click in order to deploy software! So what exactly are the gray areas that take so much time?
The problem, first of all, lies in the attitude of developers. Only few write code with a user in their minds or more specifically with the notion that it has to go live. Almost every developer that I have seen to-date takes software development as an exciting problem solving activity and never looks into those areas of the problem that seem less exciting (like security, exceptional cases, wrong input, performance issues, testing on a different environment, etc.) Since all such issues must eventually be resolved in order to go live, a lot of activity just before deployment is related to these ignored areas.
Secondly, for every piece of software to run, there are pre-requisites - like a database, service packs, a particular version of web browser, etc. Usually, the responsibility to provide these lies with the customer. However, due to the fragile and intangible nature of software (and the dear customer being naive in general), the customer expects the deployment personnel to set everything up. I am not sure how we can change the client's attitude but they say that if something is inevitable (your software sure has to go live, right?), you are better off by being part of the change rather than resisting it. After all, "whose project is it anyway?"
On a related note, I have observed a very interesting characteristic amongst human beings - if you volunteer for something, everyone thinks that it's your responsibility to lead.
So what's the point? The point, "go out and take over project management" - even if it's not your responsibility. Once you volunteer for the ownership, people will expect you to help them out - even seniors and those who don't come under your supervision will accept you as the boss!
However, there is one particular situation where I'll advise you to roll back instead of taking up the ownership: when the customer is least interested in the solution. This frequently happens when it's a low cost project or when it's merely a presales activity. Be very careful how much time to spend on a pre-sales activity and how much interest the customer has.
Deployment and software support are the most boring part of the software development life cycle (SDLC). At the same time, they are what everything else is all about. While one person might be waiting for hours for an IP to be assigned at the client side, other developers might get assigned to a brand new, exciting project. A software house should help its support engineers by improving their morale and appreciating their patience and diligence - a bonus per deployment shouldn't be surprising - after all the company gets money when the software goes live.
Isn't this gone a bit lengthy? Actually I have been waiting for more than 2 days for the client to find the keys to the printer that he has managed to loose! Software deployment is boring. Would you bet otherwise?
Limited in his nature, infinite in his desire,
Man is a fallen god who remembers heaven.
(Alphonse De Lamartine)
Thursday, June 17, 2004
Monday, June 14, 2004
Out of Town
The jaywalker is out of town and will be back in the first week of July. There won't be any postings unless he gets the piles and piles of pending work done.
"40 dirham aur do to 2000 riyal ho jain gey."
(An Arab at Dubai Aiport Money Exchange, answering my question which was in English)
"40 dirham aur do to 2000 riyal ho jain gey."
(An Arab at Dubai Aiport Money Exchange, answering my question which was in English)
Monday, June 07, 2004
Software Development Practices: Part IV - The Quality Assurance Engineers
I am of the opinion that the local QAEs (Quality Assurance Engineers) are doing a good job as compared to the developers. But they say, "Quality is a process and not a goal," indicating that there is always room for improvement.
This post identifies two very common issues with Quality Assurance and their causes.
Has your QA team ever reported anything like "this feature is difficult to comprehend for novice users" or "it takes too much time to start the application?" The activity in the arena of better software is mostly related to testing only - the whole emphasis is on finding the sequence of inputs that make the application crash and that's it. We must understand the difference between mere testing and quality assurance and thus, in a Test Engineer (TE) and a Quality Assurance Engineer (QAE).
The problem partly has its roots in non-availability of vision/ specification documents. How can the QA team report performance issues if there was no such criteria /metric defined at the start of the project? Just how easy was it meant to be? Just how fast it was supposed to be? No document in the software development life cycle is as important as the feature specification document. The QA team needs to emphasize on the availability of this document before the first testing iteration begins.
The second problem lies in the us versus them attitude between QAEs and Software Engineers (SEs). Developers, in general, don't like to re-work on something. When they are told of bugs in their software, the majority tries to shun the responsibility. Most of the time the response is, "But it works on my machine." Also, the developer gets annoyed at the very poor description of the problem. A QAE makes the problem worse by creating a mockery out of this thing. The QA people can help in changing the attitudes by being courteous and by providing a correct description of the problem as well as sufficient details for reproducing the bug.
The two problems (testing instead of quality assurance and us-versus-them attitude) have a single, common cause. There is always a knowledge gap between QAEs and Software Engineers (SEs). Certainly, a QAE isn't required to know how a particular feature is implemented but knowing internals won't hurt either. Most of the places don't require QA people to work extra hours (as compared to developers who invariably do late sittings and work more than 40 hours a week). I would advise the QA personnel to try to build expertise (in their spare time) on at the least one programming language - VB, C# and Java are very good choices. And more importantly, try to learn the inner working of Operating Systems and Application Servers. This way, you can tell what bugs/ issues are with the software you are testing and which problems are due to improper configuration of databases, OS and other third party tools. With every project try out newer ideas such as automated testing, unit testing frameworks, etc.
An organization that practices self-improvement is difficult to beat. QA folks can help by minimizing the knowledge gap that exists between them and the developers.
A fool with a tool is still a fool.
(Grady Booch)
This post identifies two very common issues with Quality Assurance and their causes.
Has your QA team ever reported anything like "this feature is difficult to comprehend for novice users" or "it takes too much time to start the application?" The activity in the arena of better software is mostly related to testing only - the whole emphasis is on finding the sequence of inputs that make the application crash and that's it. We must understand the difference between mere testing and quality assurance and thus, in a Test Engineer (TE) and a Quality Assurance Engineer (QAE).
The problem partly has its roots in non-availability of vision/ specification documents. How can the QA team report performance issues if there was no such criteria /metric defined at the start of the project? Just how easy was it meant to be? Just how fast it was supposed to be? No document in the software development life cycle is as important as the feature specification document. The QA team needs to emphasize on the availability of this document before the first testing iteration begins.
The second problem lies in the us versus them attitude between QAEs and Software Engineers (SEs). Developers, in general, don't like to re-work on something. When they are told of bugs in their software, the majority tries to shun the responsibility. Most of the time the response is, "But it works on my machine." Also, the developer gets annoyed at the very poor description of the problem. A QAE makes the problem worse by creating a mockery out of this thing. The QA people can help in changing the attitudes by being courteous and by providing a correct description of the problem as well as sufficient details for reproducing the bug.
The two problems (testing instead of quality assurance and us-versus-them attitude) have a single, common cause. There is always a knowledge gap between QAEs and Software Engineers (SEs). Certainly, a QAE isn't required to know how a particular feature is implemented but knowing internals won't hurt either. Most of the places don't require QA people to work extra hours (as compared to developers who invariably do late sittings and work more than 40 hours a week). I would advise the QA personnel to try to build expertise (in their spare time) on at the least one programming language - VB, C# and Java are very good choices. And more importantly, try to learn the inner working of Operating Systems and Application Servers. This way, you can tell what bugs/ issues are with the software you are testing and which problems are due to improper configuration of databases, OS and other third party tools. With every project try out newer ideas such as automated testing, unit testing frameworks, etc.
An organization that practices self-improvement is difficult to beat. QA folks can help by minimizing the knowledge gap that exists between them and the developers.
A fool with a tool is still a fool.
(Grady Booch)
Subscribe to:
Posts (Atom)
Posts
