Friday, March 22, 2013

The universe works agains us - entrophy!

I've been reading Stephen Hawking's The Theory of Everything this morning. He explains the entropy of black holes.

Between the lines, I was able to understand that entropy, understood as, chaos or lack of order, rises constantly. It rises because time elapses...

I got enlighted: the project or code, left alone, will get worse in time, when we do nothing.
A simple act of abstaining from action, lack of management, lack of trying to bring order, makes things worse.
This of course is just a analogy, not a law. But let's examine it..

Lack of action = lack of order

Example 1
The team works hard on developing the system. In the meantime, the test acceptance phrase takes place, and 50 bugs are reported.
The team continues the work on developing, neglecting the bugs - "we'll do it later".

That simple decission makes things worse. How? 
* broken windows (Pragmatic programmer)
* programmer is no longer responsible for delivering working code, since some things do not work already
* overall quality drops rapidly because of attitude
Lack of constant quality requirements (lack of order) makes things worse.

Example 2
The team works serveral months on a project now, and 150 bug/improvement issues are due. The project is near the deadline. The huge amount of work is discouraging - no light in a tunnel, no hope to do a good job.
For political reasons, dropping some functionality in a trade-off for quality is not going to happen. That would be a great, wise decision, but such wisdom would require a single, strong leader. This isn't happening in big bank corporations (our client is one).

I proposed some rearrangement of tasks for developers in yesterday's article; here is the summary:
A developer is required to finish the overall process/part of the system - develop all changes, fixes and improvements. He/she then signalises: "that part of the system is done".
The amount of work does not change, but the "getting work done" attitude gets a huge positive kick. The hope is restored.
Moreover, even when not everything could be done before deadline, at least most parts of the system will work perfectly.

Another example, how simple act of ordering of tacks, brings quality to the project.

And how abstaining from action, brings more trouble.

Entropy is your enemy.

 Do something, manage some change, bring order, rethink tasks... or face failure.

Thursday, March 21, 2013

Improving productivity when project gets messed up

My team is in the middle of serveral-months long development process of website for bank client. We had several stages in project, currently we are on last one.

System is soon to be opened for the world, yet quality still is poor.
There is no one part of the system we could say "it works".
As a tester, I feel it's my duty to improve overall quality.

Overloaded team

The team seems to overloaded with jira tasks. There are three kinds of them:
* totally new features (agreed upon with our client, and paid for)
* bug fixes
* improvements to existing features

Current development mode could be summarised by: "develop new features, and we'll get back to bugs later".

My first approach (after high eyebrow rise and some breathing exersises to calm myself) was: "Let's not break the system - please let's have overall quality as a first goal". This was rejected by the team.
Mainly because the project would be a political failure, should we fail to deliver 100% of requested functionality. I asked several times whether 100% functionality must work, and it seemed that "it should" :-)

Getting parts of the system done

Today I proposed another approach. When developer changes part of the system (a screen, or a process), he/she should:
* read the specification (official document detailing the way system works, the design) and make sure that particular system feature works exactly as describet
* look at jira issues, find and resolve all of task that are related to given feature/screen/process

After that, no improvements or changes are allowed. That particular feature is finished. Sure, there might be bugs, but no changes are allowed.

This way, we could get small, but importand quality improvements with each new system version (every 2 days). This way, the system would finally work properly someday.

This is only a change of view

Developers still have the same amount of work to be done. But my approach fixed the "context switch" problem and, even more importantly, leaves a feeling of job being done. Some parts of the system may now be ticked as done.
The team gets visibly closer and closer to the final goal.

My hope is that this method gets accepted...