Friday, July 21, 2006

How to improve the software performance?


This is a very old topic. A very basic requirement for software development.

Here is an approach I know some organizations adapt:

When you write the business requirements and define the functional specification, in addition to the functional behaviors, you also write the performance acceptance criteria.

Something like this:

Action: Open the XYZ window
Type: Online
Expected response Time: 3
seconds

Action: Summarize the transactional data for reporting
Type:
Batch
Max Process Time: 2 hours
You can then do this testing during your standard QA process. QA should execute the flow, run the process and record the actual time. If there are variation, they should report as issues and the engineering team can fix the problem.

Sound good, right?

We can examine the approach and underlying principle from Deming's view, from his 14 principles:

3."Cease dependence on inspection". If variation is reduced, there is no need to
inspect manufactured items for defects, because there won't be any.
8."Drive
out fear". Deming sees management by fear as counter- productive in the long term, because it prevents workers from acting in the organisation's best
interests.
11."Eliminate management by objectives". Deming saw production
targets as encouraging the delivery of poor-quality goods.
If Deming is correct, the above approach will not eliminate the problem. The above approach is basically an inspection based approach. It does not lead people to focus on the root cause, but focus on the criteria. It introduces a belief that if we are within the range, there is no issue and we do not improve the product.

I think that the key is that the system does not respect people who can really contribute to the quality of the product. As John Wookey, our leader in business application development, said People -> Process -> Product. I truly believe this. I see the suggestions are provided by Deming as well:

1."Create constancy of purpose towards improvement". Replace short-term reaction
with long-term planning.
2."Adopt the new philosophy". The implication is
that management should actually adopt his philosophy, rather than merely expect
the workforce to do so.
5."Improve constantly and forever". Constantly
strive to reduce variation.
7."Institute leadership". Deming makes a
distinction between leadership and mere supervision. The latter is quota- and
target-based.

You need to change people mind set by asking them to tell you - how we can improve our performance. This should be a never ending, continuous improvement. The people close to the code knows. They at least know how to improve the process. You hire the right, smart, talent people, give them the responsibility, and trust them. I think that it is the way to go.

As a line manager of product development, I think that these are what we can do:
9."Break down barriers between departments". Another idea central to TQM is the
concept of the 'internal customer', that each department serves not the
management, but the other departments that use its outputs.
6."Institute
training on the job". If people are inadequately trained, they will not all work
the same way, and this will introduce variation.
13."Institute education and
self-improvement".
12."Remove barriers to pride of workmanship". Many of the
other problems outlined reduce worker satisfaction.

Here are the rest of Deming's principles:

4."Move towards a single supplier for any one item." Multiple suppliers mean
variation between feedstocks.
10."Eliminate slogans". Another central TQM
idea is that it's not people who make most mistakes - it's the process they are
working within. Harassing the workforce without improving the processes they use
is counter-productive.
14."The transformation is everyone's job".

No comments: