A Wasteful Design

No, this post is not about software.
It is actually about a much simpler product, that all of us are using in our everyday life: Light Bulbs.
But unlike the usual famous joke "how many people/engineers/mathematicians it takes to replace a bulb ?", the real question is "how much does it really cost, and why ?".

http://thestoryofliberty.files.wordpress.com/2012/01/normal-light-bulb.jpg

While many still use the light bulb that didn't change since the days when Edison invented it (as in the picture above), there was a lot of recent progress in this field. Led and halogen bulbs should significantly prolong a bulb's lifespan, while reducing its energy consumption.

Unfortunately, the above advantages do not necessarily come to practice due to what I see as a "wasteful" design. I have encountered this while replacing my own halogen light bulbs in my living room.
The lamps and the lights were inherited from the previous tenant, so there was no participation from my side in the original choice...

Basically, a halogen bulb is very small, and quite cheap (about $1.5 USD). It is a very small component, and the only thing that needs to be replaced when it burns out.

http://www.absak.com/catalog/images/bi-pin-halogen.jpg

However, the bulbs I had installed, were packed as a much more complex unit, that needs to be replaced as a whole unit, you could not replace just the small halogen bulb component.

Exhibit 1 (price - about $10 USD)

Exhibit 1

Exhibit 2 (price - about $15 USD)

Exhibit 2

As you can see, quite a lot of material goes to waste here, while it could have been saved, by replacing just the small halogen bulb in the center. It could also save the consumer (me, in this case) quite a lot of money (consider that I have 4 bulbs of each kind in use, and they need to be replaced roughly every couple of years).

So why do the manufacturers design it this way ?
The naive answers would probably be: "to make the replacement process easier", "to make them more compatible", etc... This might be true for the 2nd exhibit but definitely not for the first one (where two bolts needed to be unscrewed just to pull it out).

The truth is that they are probably trying to capture the maximum "willingness to pay" of the customer. They figure out that if someone acquired this lighting in the first place, their "willingness to pay" is high enough so as to pay the additional $50-70 USD for the additional bulbs every couple of years. Of course, their own (as well as of the retailers) profit margin on such products is much higher, and these products are much more profitable than just the simple halogen bulbs.

So, I guess this is yet another case where the manufacturers make the consumer pay much more than necessary, without the consumer being able to do anything about it.

But even if we put the consumer cost aside, the environmental footprint of such products is so much higher than of the simple part that really needs to be replaced (all this plastic, aluminium and other metals that go to garbage unnecessary).
Why do the future generations have to suffer because of greedy manufacturers creating a wasteful design on purpose ?

A final thought - when choosing your next lighting, make sure you really understand the economic and environmental cost of having the bulbs replaced.

Debugging Shufersal Targeted Promotions

My wife and I are frequent customers of Shufersal, a major Israeli food retailer, as there is a store near our house. We even have a membership card, and use it every time we make any purchases.
From time to time, Shufersal send us coupons by mail, that seem to be tailored to our needs.

7 months ago our baby was born, and so our consuming habits changed. Diapers and milk formula became part of our weekly shopping. But Shufersal prices for these items are relatively high, and so we barely ever bought them there, and instead always bought them in pharma stores (mainly Superpharm), or online, upon promotions. But we did shop for few baby-related items there, so Shufersal could know through the membership card usage that we now shop for a baby.

It seems that recently Shufersal decided to find out what are the exact brands that we are consuming (as you probably know, customers are usually very loyal to specific brands and products, when it comes to babies - "if it works, don't change it").
They have sent us very attractively priced coupons for every possible milk formula products, baby food products, diapers, bottles, etc... Naturally, we did use the few that were really relevant for us.

Now I wonder what will happen next. Will we receive more coupons for the products we purchased ? Will they be priced equally attractively ? Did we disclose our customer preference and willingness-to-pay limit through the coupons ? Will they try to affect our preference by suggesting low prices for substitute brands ?

Updates will follow...

Decisions

I have recently read two articles on "Decisions Fatigue": one was published in NY Times, the other one - in this blog post. This got me thinking - do development managers and team leaders suffer from such decision fatigue as well ?

It seems that in many cases, the management level that directly manages software engineers takes much more decisions than necessary, going into much more details, and do not empower enough the individual engineers to take more decisions, and also be accountable for the results of these decisions.

I am sure that those engineers who are willing to step up, indeed do so and take many decisions themselves (such as described in the 2nd post), when properly empowered by their managers. But what about those that do not do so ? They seem to be in a very convenient position, where their manager does most of the decisions, and then also faces all the consequences in case of a failure, while they are at most the "innocent bystanders".

Now, in real life, the vast majority of these people are able to take a lot of very important decisions: organizing their wedding, buying a new apartment, taking care of their children and elders, etc. All these decisions seem to be much more difficult than some decisions on design, user experience, quality, priorities or any other decisions that a software engineer might need to take in the day-to-day work.
So what is different ? Well, in real life there is no manager to take the decision instead, the person needs to take these decisions and be accountable for the results.

Now, someone would ask: what do we need the managers for then ? Why do we, the developers, need to take all the responsibility, where is the responsibility of the manager ?
Well, the responsibility of the managers is to determine which decisions can be taken directly by the people they manage, help these people by teaching them and providing them the tools to make such decisions, and setting the standards and expectations for these decisions and their outcome. Eventually, the managers are accountable for any outcome of the work done by the people they manage (both for failures and for success), but the point here is that each and every individual should be equally accountable as well for their work.

Now, what does it all have to do with decision fatigue ? Same as discussed regarding the engineers' decision fatigue in the 2nd blog post, a manager also can process only a limited amount of input every day, and take a limited amount of decisions.
The results of such decision fatigue can be truly devastating for the product:

• Setting incorrect priorities
• Settling for the "quick-and-dirty" solutions just so as to remove the problem from the pile of unresolved issues, instead of making sure that there is an adequate design
• Not creating a long-term strategy for the product
• Developing features that have bad user experience, only because we didn't put more effort into designing their usability better
• Taking technical decisions that result in bad performance and scale problems later on
• Taking decisions that do not address well enough some people's aspirations for personal development, etc...

If more decisions were taken directly by the engineers, the managers would have more mental capacity for taking the more strategic decisions, that have more effect in the long-term, and in fact do more of the decisions that they were so far pushed up to their managers or aside to the product manager/owner or the product architects.

From my experience in implementing these principles so far, I can say that it worked better in some cases and worth in other. Here are some of the pitfalls to avoid:

• The engineers are provided with too much decision freedom, and as a result decisions are taken in a counter-productive direction (focusing on things that are not important, etc...).
• Need to identify cases when the engineers do not have the tools to reach the decision on their own, and they do need extra guidance. Otherwise, the process can come to a hold due to no one taking a decision.
• In order to take decisions, the engineers need to have sufficient information. The managers must be an "information hub" in this sense - pushing the relevant information to the relevant individuals.
• Sometimes the outcome of the decision has a very meaningful impact and the engineers do not feel comfortable taking such a decision on their own.

To sum it all up, I do believe that following the above principles, when implemented properly, will benefit both  the software engineers and their managers, by extending the scope of their day-to-day work, providing more  freedom to their work process, and enabling everyone to take better decisions where it really matters.

Processing feedback (a retrospective)

Wow - never thought that my recent post (Software In Pictures) would become so popular.
Almost 700 views during 2 weeks, and still counting !

I have also received a lot of comments, and the post contents were even discussed in a couple of Linkedin groups. As a junior blogger, I find this very encouraging.

However, naturally, not all feedback is good:
- Some people did not like my "good code" metaphor.
- Some of the other examples were put in other contexts, where they are actually welcome and functional, with good cost-efficiency (such as the door in the wall, that can be used to load goods to an upper floor).
- Some of my examples were seen as possibly offending to the less fortunate populations, that come to these solutions out of necessity, and without a better option.

What I learn from all that:
- The more people read your blog, the more feedback you will receive. And a certain portion of it will be criticism.
- People seem to be more encouraged commenting on topic upon which they disagree, than on topics they do agree upon.
- All feedback is good and welcome. The more feedback I will get for my posts, the more I will learn and the better my next posts will become.
- The more often I write, the shorter will these improvement cycles be.

When thinking of it, it's not so different from building a new product.
As you start, and produce your first prototypes, or even the 1.0 release, most of the feedback will be negative - as chances are that your initial product will suck in some areas.
By collecting the feedback, processing it, and learning from it, you will gradually improve and so will the product.
The negative feedback is indeed the preferred one, since it can help you understand where to focus your next efforts.

So, my bottom line for all the bloggers out there is: write, get feedback, process it, rinse and repeat.
And the same - for the all the product developers out these.
And the more frequently you write/release, the faster the improvement process will happen.

Software in pictures

Did you ever try to explain what is "bad code" to someone who does not come from software background ? How do you do that ?
In this post, I would like to visualize some bad design and coding using some real life parallels.

But first a disclaimer: as bad as many of the following examples look like, sometimes compromises need to be made - to meet a short-term deadline, to save cost in the short-term, due to temporary lack of expertise, making some feature work for a customer on the spot, etc.
As long as you acknowledge in advance that what you did is not the right way to do it, and are willing to improve and proceed to apply the proper solution...

First, let's take a look at the equivalent of some messy code.

Source: http://bit.ly/jmL7RC

Source: http://bit.ly/kiWmRV

When one of the power lines dysfunctions, how long do you think it would take to fix it ? Or just to find it ?

Same is with bugs in code that looks like this...

Now, how about using a workaround solution rather than upgrading the infrastructure to handle it properly ?

Source: http://bit.ly/myfL5v

Sometimes, just because you can make two pieces of software work together doesn't mean you should:

Source: http://bit.ly/lpx3vE

Here is how it looks like when you apply a patch rather than rewriting a broken piece of code:

Source: http://bit.ly/iYIyAa

And finally, this how is it looks like when you leave some useless code around:

Source: http://bit.ly/jfFKqE

For contrast, here is the probable visualization of a good piece of software - fast, sleek, great design, and it gets you to where you want to go to:

Source: http://bit.ly/jpZAGU

Do you have any more similar design or code visualizations ?

Your code - keep it covered !

Code coverage by unit-tests (or integration tests - we will not discuss the differences here) is the easiest to add - in many cases much simpler than adding complex end-to-end system tests, and provides good protection against many stupid and easy-to-detect bugs. Here I am only referring to tests that take just a few minutes to run, and can be run as part of the basic build process. No one is saying that it makes the code full-proof against bugs, but no one can argue that having ready tests reduces risks when having to fix a bug or make functionality changes in some code. Code coverage measurement tools are able to provide reports on the portions of code covered by these tests.

Naturally, some developers are adding much more tests on average than others. I don't know where does the lack of writing tests come from - is it out of pressure to meet a deadline, lack of skills or experience, laziness, just not caring, not presenting a sense of ownership ("it's someone else problem"), or any other reason... Also, sometimes, for the same reasons, people tend to remove or disable tests rather than fixing them - either at the same moment, or shortly after committing the code that broke these tests. This, inevitably, leads to having the coverage percentage going down.

Quite for some time, I have been thinking about a method that will hopefully continuously increase code coverage by tests. I am sure that I am not inventing anything new here, but so far I did not encounter any teams that are actually using such a method, and anyway - this is a great way to get feedback on ideas :)

Continuous integration tools, such as Jenkings (former Hudson), have appropriate plugins for displaying code coverage results over time (see a screenshot example) . Moreover, these tools can be configured to mark the build as failed, if the code coverage percentage for the current revision is lower than for the previous revision.
This way, if someone commits code with lower coverage percentage than the current percentage in the trunk  (by not writing enough tests for the new/fixed code, or disabling existing tests), the build will be broken, just as if this person committed code that doesn't compile, or caused any tests to fail, and it will require a similar response (either provide a quick fix, or revert the commit).

For example, let's say we start the process at the current state, and we have 40% code coverage by such measurable automatic tests. The above process ensures that we will never go below this coverage percentage. But how do we go up ? Well, statistically, some of the developers will have much higher code coverage on their code, thus moving the overall average higher. This will automatically set a new, higher, goal from that moment on.

But what if adding more tests for some specific change is highly difficult and is not cost effective ?
Well, my suggestion is that in this case, since the developers do not want to break the build, they much compensate by adding tests for different (possibly even unrelated) code, merely so that the overall coverage won't go down. Over time, such an "escape route" will ensure that at least all the easy-to-test areas in code will be well covered.

Of course, reaching 100% coverage is virtually impossible, and also at most times non cost-effective. So we can set a lower percentage threshold (75-85%) for coverage, and once reached, just make sure that the coverage does not go below this threshold. In addition, at all times the code that still does not have code coverage, will be the code for which writing tests is the least cost-effective, or that is better to be covered by more complex system tests, that cannot be run as part of the continuous integration system measurement tools.

I am sure that such an approach is a bit controversial, so I would be happy to hear feedbacks and suggestions how to improve such a method.
My main concern for adoption of such a method is the social concern - how well will it be perceived by the developers, will the developers that indeed lowered the coverage percentage take the responsibility to fix it quickly, or will there be just a continuously "red" continuous integration system status, that no one cares about...

I must say that I still do not have any actual experience or results for this method. Hopefully we will be able to try it in our group in the next months.
I will update on any insights and conclusions as we go...

Creativity where you don't expect it

Recently, I have encountered two seemingly unusual examples of businesses trying to provide additional value to customers in some rather surprising ways.

The first would be the funerals market (you might have already seen it on the Jimmy Kimmel show last week). What can possibly be innovated in this market ? Well, in Compton, California, the Robert L. Adams Mortuary  are now offering a new product: a "drive-by mortuary" - you can drive-through near the open casket of the deceased and depart from the beloved one, all that without even having to leave the comfort of your car.

The second innovator would be McDonald's, that are now offering wedding packages in their branches in Hong-Kong. Apparently, this allows many Hong-Kong citizens the opportunity to get married at reasonable prices, as compared to their other options. McDonald's even offer to supply wedding gowns, made out of balloons, for the happy brides.
So next time you're eating a Big Mac in Hong-Kong, be careful with that ketchup - a bride in a white dress might be just behind you.

Both cases, while probably being rather amusing for a person coming from a different cultural background, are actually great examples of "thinking out of the box". Both are created in rather traditional businesses, they seem to create additional value for their customers and thus increase revenues, without any substantial changes or investments in their business core. So you have to admire the creativity of the marketing and product managers behind these offers.

Makes you think what kind of "additional value" can you create with your software products, with some very little additional investment in development...