The Failing of Competition

The failing of monopolies, whether state imposed or gained in domination of a free market, is that they tend to stagnate. Without competition there is little motivation to do well. Why seek out better ideas when no one will cut into your market by thinking of them first? Why treat your customers well if there is no one else to turn to? Competition drives businesses to look out for their customers, because if they don't, someone else will.

But there is a major failing to competition. The drive to win over customers often requires that they be won over first. When decisions to purchase a commodity are difficult to turn back on it means the spoils go to the quick. But to be the first with a new and attractive service often means compromise.

When pushing to be first, many things may be put aside. Planning, testing, thinking. Steps essentially to ensuring quality are lost sight of or begrudgingly laid aside as pressure comes down to meet deadlines too tight to do well, but that gain an edge over the competition. This pressure can lead businesses to do what individuals otherwise would not do.

If something is foolish or considered wrong, and individual would not do this for themselves. Why would they do something that clearly would cause problems later on? Why would they do something that is a compromise of character, vices and addictions aside?

But what about when it is your employer asking for the foolish act? Defenses may already be down as the worker is concerned about their job security. But added to that, though they may acknowledge the act as foolish, it is still what the boss wants. The boss can see the compromise as well as them, and the compromise is what they want. So workers are led to compromise because the compromise is not their own. In some cases it may seem small, only resulting in minor headaches for customers and the company down the road. In others it can lead to reprehensible actions.

On the flip side, though monopolies are seen as the breeding ground of stagnation and neglect this is not always the case. There have been monopolies that for the pride of their work have innovated against the trend. They have not succumb to what is easy.

The point then, is that it is not necessarily the circumstance that must guide business. Whether it is a monopoly or a competition there are decisions to be made. The decisions may be to go with what seems the natural route. To dismiss the customers needs as they have no other options. Or to scramble to out pace the competition, regardless of the long term cost. But what is needful is men who will make decisions to do what is right. Who will do what is good in the long run, both for customers and for the business, whatever the prevailing pressures may be.

Software Design at the Source

I just finished Norman's The Design of Everyday Things. As the name suggest it's a look at how the things of everyday life are designed, both the successes and mistakes. I think it'd be an interesting read even for those who aren't involved with design. If you've ever used something wondering why it is so difficult to use, you'll appreciate the direction in looking for products that are well designed.

I read the book primarily for my work to get a better understanding of how to design software. Unfortunately due to when it was written it doesn't cover much on computers. Some of the principles apply, but it seemed every shortcoming or difficulty in the real world applies doubly in software. Though software also can potentially provide opportunities around all these shortcomings, reading it helped me understand why software design can be so difficult.

One thought that stuck me as I was pondering the principles of design proposed is how important design is in software. Not just for the end user, but in the source code itself.for the sake of the programmer. I'm not just talking about efficiency or correctness, but a user-friendliness of the source code. This isn't anything revolutionary, I'm sure. Plenty has been said about making code readable, and on how to design code. But it certainly struck me, and made plain the reason for many of the problems I am facing with the code I work with.

To make this understandable for both the developer and the layman, let me first attempt to describe source code to you. Source code is essentially instructions for carrying out a set of processes or actions. It is often compared to a recipe. If you follow the instructions of a recipe as written you will get the results desired. But if you were to randomly rearrange the recipe, it might not work. If the recipe called for placing the dish in the oven after turning the oven off rather than right after preheating it the results would be less than desirable. So it is with source code—if all the right instructions are in the wrong places the results won't be what was intended.

Now we could compare a computer to a chef, but that doesn't quite give us the picture. A chef seeing the mixed up recipe above would correct it, probably without even realizing there was a mistake to begin with. But a computer will perform the instructions exactly as it is given. So let us consider a robot chef who follows his instructions to the letter.

But this description still falls shy. Software can be composed of hundreds thousands of lines of code. It covers a wide variety of tasks that the user may trigger at any time. So let us take our robot chef away from his simple recipe, and place him in charge of catering a wedding. And not just any wedding, a week long affair like in India or the Middle East. Now our chef has hundreds of dishes to prepare, and all of them simultaneously. The appetizers, the main course, the deserts. Breakfast, lunch and dinner. Now you begin to see the magnitude of the task of writing a proper program.

So our robot chef has his source code—his list of recipes—and when each part of each recipe is to be performed. He performs each task without deviation, exactly as described. A wonder of modern technology! But alas, the description is wrong! He is putting garlic in the smoothies and too much salt in the omelettes. He consistently burns a dish from the main course, and in one recipe is using motor oil instead of olive oil. Exactly as we asked him to do, but not what we intended! Now we need to find those incorrect instructions and fix them.

But where! Now the problem becomes clear. The number of instructions given our robot chef to prepare the week long banquet is overwhelming. Where do we even hope to begin? Well, you say, let's start somewhere simple. We know he is putting too much salt in the omelets. Just pull out that recipe and update the salt amount.

Now we have stumbled upon one of the first important principles of design. That the user of a design assumes a model of the design. You have assumed (or so I assume) that we have written our source code in such a way that each recipe is independent. The robot simply goes from one recipe to the next. But what if this is not the real model? What if in reality the recipes are all broken up into parts—prep, mix, heat, and serve—and are mixed together for all the recipes? The robot cracks the eggs for the omelet right along with the eggs for the pancakes. He cuts up the veggies for the omelet with the potatoes for the hash browns. The robot is working on everything simultaneously. This model, with all the recipes seemingly mixed together is a little more complicated, and perhaps harder to understand. But it is understandable enough, and presents a clear model for the programmer who manages our robot.

This is the first key. The programmer is in fact also a user of the source code. Just as a casual observer of our robot chef would come up with a model of how he organizes our work, so too will our programmer come up with a model. And his model needs to match the actual model that is described by the source code. Otherwise he will find it difficult to edit. Unfortunately most code is written without any sort of model defined, making it near impossible for a programmer to find a coherent model to follow.

For instance the original programmer probably first just wanted to make omelets. So his model was one recipe sheet for the omelet. No separation of the steps to prepare the omelet. Just lump everything in one place. Then his boss realized there was money to be made not just in omelets, but in breakfast. Now he's added pancakes, hash browns, fresh orange juice and a side of toast, drizzled in strawberry compote. And he kept each recipe separate to keep in understandable. Good work programmer!

Yet this doesn't work. Everyone is getting their breakfast too late. They get their hash browns first, but by the time the pancakes are ready, the hash browns have gone cold. Now he has to reorganize, putting the first steps of each recipe together, and the second steps, and so on, so that everything is on the griddle at just the right time to all be served together, as described above. But he just put all the steps in one long list without taking the time to organize them so as to match a clear model.with understandable sections: Prep, Mix, Heat, Serve. Before he can do this he had to move onto project "lunch."

Now we've arrived at our recipe list for the wedding banquet and need to track down how we end up with too much salt in the omelet. But was the omelet itemB or itemD in that long list of instructions? Our programmer didn't think to identify things very well since at first everything was separate, and the separation itself made it clear what was what. But now that every recipe is mixed together we'll have to read through the whole recipe until we can find something that identifies which one is the omelet. We can't necessarily look for a high salt value as the hash browns also need salt, and they need more than the omelet.

Here in is the root of the problem. If we don't have a good model in the code, things are hard to understand and debug (i.e. remove problems). As more things are added to the program things get worse. When you add a new recipe to the mix, throwing it in anywhere seems fine if there is no clear place to put it, making it less and less clear what piece of code belongs to which task.

What's worse is in real code we have plenty of more things to confuse us. Frequently the worst code will not only be poorly organize, but we also be poorly labeled as in our itemB and itemD example. We'll have a piece that says MakeItemC, but what in the world is that. I guess we have to look at the recipe in MakeItemC to find out. Hmmm. It's compromised of Step1, Step3, Step4, and PtOvn. Oops. Turns out itemC was a quiche. Had they labeled it MakeQuiche we would have known never to look here, as the quiche doesn't have enough salt if anything! Now we've just wasted our time following what should have been an obvious dead end if the code was user-friendly.

Unfortunately this can be quite bad, and quite easy for software companies to not understand this. It is easy to miss because at first your source code is too small to be misunderstood. Plus there is only one guy writing the code, so as long as he understands it things are good. But this early failure to keep things in check, and to have a clear plan of how the source code should be organized quickly balloons. Suddenly they are getting successful, and hiring more developers. Now they have 20 who are all writing things their own way, and nothing quite matches up. That's fine as long as we keep them on their own projects.

Oh no! Now some people are leaving. How can we get to the bottom of their code? And now we're up to 500 programmers, and we need to get everyone up to speed in a couple weeks. How are we ever going to manage that? If only we had kept things organized at the beginning but now it's too late. Let's just try to keep things organized from here on out, and minimize changes to that old garbage. It's been running all these years anyway. I'm sure no more bugs will pop up, right?


Open source code can have a potential advantage in this area because the code is much more of an asset. Programmers don't have to work on open source projects if they don't want to. So if the code is a jumbled disorganized mess, they will take one look at it, grimace, and wish the maintainer luck before trying to find a project that looks more manageable. I know the few times I've dug into the source code of an open source project it took me only a few minutes to get up to speed, whereas at work it can take the better part of a day or month. Even then I often only understand things well enough to fix it with some assurance I didn't make things worse.

If businesses thought about it, they would realize that taking the time to design their code well is money well spent. I'm not going to say it takes little effort up front to make this happen, as the effort is certainly significant. Especially as things grow it may be necessary to completely reorganize core concepts in order to keep things orderly and understandable. But it will save thousands of hours down the road. Less time will be spent bringing new programmers up to speed as they can quickly be told the rough flow of the source code. And it will be accurate! They won't constantly have to learn something completely different for each piece of code they touch, but just enough to locate the problem and fix it.

Just as when software is user-friendly, it provides a better experience for the user, when source code is coder-friendly, it provides a better experience for the programmer. It allows them to take less time to make fixes and add new features, all with reduced chance of introducing bugs. And that is something that benefits everyone.

Why Manufacturers Must Become the Recyclers

As I mentioned in my last entry, it is better to reduce or reuse than to recycle. But there are some products considered necessary that must be recycled as they are either used up (e.g. light bulbs), become dated (e.g. computers), or otherwise. The typical view of how to provide recycling for such products is to leave the burden on the consumer. That is, they need to find an entity that collects and recycles such products, and pay for the services when they are done with the product.

There are several problems with this. First, it is often difficult to find such entities for recycling products. When found, they may only accept certain types of products, and not all those that the consumer wishes to recycle, meaning more searching. And collection times are often rare for community based programs, meaning the consumer has to not only discover when those times are, but stockpile their recyclables for that occasion. Second, the recycling venues are out of the way, and not part of the consumers typical route.

Third, it is difficult to judge demand for recycling, as the typical response to no recycling options is to just throw something away. Thus not many recycling outlets pop-up. Fourth, it is an additional charge to the consumer, which they would probably pay without thinking if included in the products purchase price, but is a deal breaker coming at the end of the products use. "Why should I have to pay when I'm doing something good?"

Finally, it is going to be expensive. Products will generally not be built to recycle as the manufacturer has no stake in the recycling process. Thus recycling is likely to be difficult. Not designing paint to easily be stripped from plastic either results in an expensive separation process, or an ineffective one where the paint mixes in with the plastic resulting in an inferior material. And there is not much the recycler can do about this as they have no control over the manufacturing process. As a result, they probably won't recycle much of the material they receive.

This is the key reason I believe the recycling burden must fall on the manufacturer. They are the only one capable of controlling how recyclable a product is, and the best way to encourage them to make such products is to have them invested in the recycling process. As they will be passing the cost of recycling on to the consumer (or eating it) they'll have a strong desire to cut that cost. Thus they will make products that can easily be separated into their recyclable components. Further, the manufacturer will have a stronger incentive to meet any regulations of what must be recycled, and may not even need regulations as they see that recycling means they can be the ones to reuse the material, and cut the cost of buying new material.


Now unless consumer pressure is great enough (and it generally isn't) this will need to be a government enforced practice. And as common knowledge dictates, any regulation creates an incredible burden for businesses. And what is bad for businesses is bad for the economy.

Except companies that have started making more sustainable products have generally found it to be an advantage. They now can just reclaim old materials, rather than have to pay for new materials, the cost of which is likely to rise as resources become more scarce, and shipping costs rise with energy costs.

The actual burden comes when a business tries to make the switch when no one else has. Whether doing it for environmental reasons or the long term cost benefits, the initial steps can be costly and can be a disadvantage when their short sighted competitors don't follow suit. A business wanting to take these steps may feel they can't due to these factors. And it's likely that businesses have had to make this unfortunate decision. But if it's a government requirement, this burden disappears. Even those short sighted businesses don't have to pay for their lack of vision.

Though all those extra costs are still bad for the economy, right? Having to pay all those extra workers to research better manufacturing and recycling techniques, and even more workers to implement them. Just think of all the extra money being spent by these workers, and circulating through the economy. I don't understand why these burdens are so popularly held as the bane of our economy.

Though one possible pitfall is if some companies want to avoid these regulations and move elsewhere.

---

A few points of how I think this process should work:

Companies would have to provide a product collection service through the same channels as their products are sold, making it easy for the consumer to return recyclables, and solving the second problem mentioned above. Businesses would only be liable so far as providing the necessary means for consumers to return products, and then recycling those products, but not for any product the careless consumer sends to the landfill. The recycling could either be handled in house, or through an outside contract.

I believe requiring manufactures to provide recycling, rather than ensuring the products meet certain recycling specifications is the better way to go. Specifications, are likely to be broken, not allowing for some novel recycling methods, and hurting businesses that may be able to recycle their products, but not according to the specifications. Further, something so narrow is likely to have loopholes that break the system. Requiring manufacturer recycling programs, on the other hand, will allow capitalism to work its magic as manufacturers search for the best way to build and recycle their products.

That said, it may be difficult to set that standard for what constitutes recycling of the product. Currently, it may be difficult to recycle all components of a product up to a given standard. A reasonable regulation could be "x% of the product must be recycled to be used for y product life cycles, with no toxic materials from a specified list be dumped." With x, and y differing between industries, and increasing in a predictable fashion. Incentives could also be given to encourage manufacturers to go beyond the current standard.

Walmart: Green is also the Color of Money

So yesterday was earthday, and I caught the end of a Walmart commercial telling the viewer how shopping at Walmart can be environmentally friendly. It had something to do with a detergent bottle, and the bottle's wide cap sparked a bit of hope in me.

Perhaps the wide cap was to make it easier to refill the bottle. Instead of shipping in individual bottles that will be thrown away or recycled, the consumer will buy one bottle for a lifetime and refill the detergent at the store. Remember "Reduce, Reuse, Recycle" means that reusing something is better than recycling, as recycle takes energy, and frequently results in inferior materials (known as downcycling).

The reality is, however, that the detergent is more powerful, meaning you need less detergent. So instead of buying a bunch of large bottles, you buy the same amount of smaller bottles and are able to wash the same amount of clothes with a little less packaging. A step in the right direction, but not a very big one.

A better solution would be to put the more powerful detergent in the same large bottles, as with a slight increase in packaging (surface area) you can greatly increase the amount of product (volume). An even better solution would be to eliminate liquid detergents, and only ship dry detergents. With liquid detergents you're paying to have water shipped, which your washing machine already provides (Cradle to Cradle, page 142). Also the extra weight means more CO2 is emitted in transport. Of course the best solution would be reusable containers, following the same reasoning Walmart gives for using cloth bags.

Of course, as a business, Walmarts main focus is on selling products, not saving the environment. They suggest that if every Walmart customer bought a pair of organic pajama pants it would reduce the amount of pesticides used. The effect that isn't mentioned is it would generate a lot of revenue for Walmart. Of course the better option would be for every Walmart customer to use the pair of pajama pants they already own, and if they Need to buy a new pair, to buy organic.

In all likelihood, what Walmart is really doing is greenwashing their image; making people think they are helping the environment, while only doing minimal measures to improve their image so they can increase revenue. In fact, the 10 things you can do to save money and make a difference fall into two categories: 1. doing something different at home (no burden on Walmart), 2. buying something from Walmart that they were probably going to sell anyway. The good news is it seems that when a company greenwashes their image, that eventually people find out where they are falling short, and pressure forces them to actually improve their policies. Though your average Walmart shopper isn't very concerned with social justice issues, and probably won't notice if they fall short on their environmentally friendly claims.


Now a real show of concern by Walmart would be to take on the burden of a recycling program for all those CFLs they are going to sell.