Do not assume existence of any data when creating a uptime monitoring sensor.

AlertFox

I've been evaluating AlertFox monitoring service lately, which I like alot.
It has awesome features, killing instantly services like pingdom.com.
I'm able to do anything on my site that a real user can - javascript pitfalls are not a problem.

I also get a screenshot of a problematic situation, which is priceless in case of a 500 error (it contains the error_id that leads programmers to stacktrace. Pretty useful, right?).

To monitor if the website was working properly I created a script that:

• enters website and uses search bar 
• evaluates if the product was found

It worked like charm till yesterday 10:00 AM. Got a alert e-mail saying that the site was down 50% of a time. So I went to customer service with that info, to notify them of the problem. 

It turned out to be a false alarm sadly. The product was no longer available, it was deleted.

Lessons learned

• Do not assume as constant the existence of data or (editable) labels when creating a uptime monitoring sensor
• Rely instead only on code features, and even then - watch out for system updates
• Simpler is again better

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.

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...

The hidden cost of bad implementation

We have two systems integrated: one processes the internet form and outputs a XML (the forms system), the other receives and stores the output and processes further user input (the frontend system).

For economical reasons the output is stored as text (CLOB) in database, violating the principles of rational relational database usage.

The alternatives were:

1. a dedicated table (entity) that would need to be changed everytime the other system changed 
2. table with attributes: form_id | field_name | field_value 
3. dynamic class with .toXML_CLOB() and .readFromXML_CLOB() methods to parse the XML

The first idea was rejected because it was unpractical - changes to XML output would break the integration. The changes to forms system are unpredictable and the solution was rightly rejected.

The second idea was used in some systems previously in our company and served us well.  I've maintained such systems for 4 years. I liked possibility of mass update of fields in case of :

• application needing different format of value
• app ceasing to accept some values/value ranges

The third idea is riddiculous in static java world.

The rationale

The reason simple text storage was choosen was that very little bugs or updates were expected. This turned out to be true, because of enormous experience of team making this decission. Bear in mind hovewer, that it might have turned otherwise.
The type of decission is beeing called 'engeeneering 95% decission', which means that is is solves 95% of requirements/problems.

The misscalculation

But was it truely the effective decission or unwise bow to the budget? Please notice, that the implementation cost of field_name | field_value table is not very much higher than CLOB. I'd say 2 or 3 times more work (max 40 hours more). And we're talking about two year project in team of 15 people. And we're talking about integration.

Integration is something that can't be easly changed once it starts being used.

The hidden cost

What was not taken under consideration are the lost opportunities of good software. The value and stability of well written app is stressed across many books and lectures in the field. Yet it gets forgotten so often.

Let's explore the opportunities of good, simple implementation field_name | field_value. Those are things easly done with this implementation and very hard to be done upon XML CLOB:

• mass update of date format
• when a field may no longer be empty, a mass update of default value is easly done
• analysys of values in specified field is easly deliverable
• one may search for a form with specified e-mail
• easy duplicate values (e-mails to be precise) detection and rising alerts
• additional business-critical validation of user-entered values is possible. Some data is unavailable for forms system but is available in frontend system. Some critical assumptions could be tested (and re-tested) after form has been submitted.
• any request to alter or analyse forms data would be reasonably priced. Reasonable pricing of simple operations is good. Prohibitive prices for simple things are very, very bad for business relations.
• alternate ways to deliver the forms data to the system would be easly possible - the frontend system would have a possibility to become some kind of center of processing data. Good for business, right?

Summary

1. Good implementation delivers higher value to customer who paid for the system.
2. Good implementation allows better business-to-business relations
3. Good implementation allows system to grow and become a importand bond between business partners

The hidden cost are those lost opportunities.

Fix on four branches

Commit this to following four branches

Yesterday one of developers in my project got a message to commit her changes to four branches in central repository. I said "you must be kidding me" and immediately went to investigate.

We develop new features on separate branches and cherry pick them to release candidate branch that is put to testing and possibly deployed on production. There is also a "master" branch for non-client requested changes and a branch for immediate fixes on production.

As the fix was needed by two different changes (branches), two commits seemed reasonable. What about the master and "fixex" branch?

It turned out that the developer in charge of changes process requested immediate merge to those two branches in fear of someone taking over him (less experienced programmer) might have trouble applying the patch without errors upon master and/or fixex branch also needining this fix.

So some part of new feature was developed on branch, needed the fix, but the fix was also to be applied to other branches is case the changes were to be added to those branches.

This is bad. This is anticipating a problem that did has not yet happened. This potentially breaks the stable branches (not requested, surprise change). This a real problem of trust and leadership.

Don't do it, please. Trust your co-workers to do the good job. Anticipate problems by documending prodedure and quirks. Advice and help verbally. But do not spoil the code.

Simple statistics alghoritm that beats A/B methodology hands down

http://stevehanov.ca/blog/index.php?id=132

The alghoritm shows [Buy me!] button in 3 different colors. If user clicks it, "click through ration" for color is risen. It user does not, it's lowered. After 100 clicks (and thousands of visits) one gets very good estimate of both click througrh ratio and which button works best.

Simple.

The Top 10 Ways to get screwed by the "C" programming language

http://www.andromeda.com/people/ddyer/topten.html

My favorite is 16. Octal numbers.
This made it to Javascript even. So obviously stupid, yet survives..