Software Development

I want to switch gears and talk about a Google Tech Talk I saw a while back. It's called Competing on the Basis of Speed. It was surprisingly good and isn't what I thought it would be. One idea was to implement multiple solutions at once. And we're talking ideas that translate to software here. I remember two of the examples given. One was a car manufacturer who developed many different engines for the same car. I don't remember the exact number, but it was in the double digits. Only one of these engines would be used in the final product. Aren't all these other models wasted? No. For one, you learn everything you can about producing those kinds of engines. Some of these were used in future models of vehicles. They also were able to streamline their engine production that would have been impossible if they only chose to build one engine. What's more, they were able to make a critical decision (choosing the right engine) as late as possible when they had the most information available.

The other example was a scanner that could read handwriting or something like that. They could produce a simple algorithm in a short amount of time, but it did not work very well. Or they could produce a complex algorithm would take quite a few months to develop. The correct answer is to develop both. If you can't get the complex algorithm done in time, then the profits from the bad algorithm can be used to pay for the development of the better algorithm. Sometimes, not perfect is better than nothing. It can still save a lot of time from people who have to convert the information.

I haven't watched the video in a while, so the exact details may be off a little. But the gist of it is the same. Convincing a company to fund something that will be thrown away or wasted is not an easy one. Also, funding two separate implementations when only one can be used instead of sequentially implementing them is not intuitive. But there are plenty of success stories that demonstrate that trying many solutions works better than one. Comic books sure tried everything they could. Businesses usually succeed the second or third time around. Not only because they learned a lot, but because they have a second or third idea. If you only have one idea and it doesn't work, you're out of luck. It's also said that students who go back to University or College the second time around have a huge probability of graduating. This is more about commitment, but sometimes they change majors. This does not mean you need to study many different areas at once, but that until you test the waters, you won't know for sure what is right for you.

1. Try multiple solutions.
2. Wait until the last possible moment to make a critical decision.
3. Refine the best solution.

That third step is the refactoring step. If you haven't done the other two steps, you'll end up doing them in the later steps anyhow whether you like it or not.

In Project V, I ended up doing this several times already. I'm programming this myself, so it's not like I had much of a choice, but having the resource to do otherwise, it's a good lesson to learn. I think I've tried at least five different type systems. Each one was not necessarily better than the last. But each one got closer to what my goals were. In fact, each one helped to clarify what those goals were. It's a known fact that you always have a better idea of what you want once you see something in action. Just ask real estate agents. People know what they like once they see it. But before then, it's difficult to pinpoint. Just think of a work of art. How do you know of the art you like before someone even conceives of it? It just doesn't work that way. And ironically, this often infuriates programmers when they suffer from the same problem. For example, software development will always improve, but try to get a programmer who believes the self fulfilling prophecy that there is no Silver Bullet as to what he or she would like best as a new development platform that has not been created yet. It can't be done. If it could, we could predict the future (ahem).

Another example where I tried different solutions was the GUI. It's funny tracing the evolution of it. It ended up having quite a few similarities with the way Windows handles its GUI. And Windows looks similar to the way the Amiga OS's Intuition GUI system was handled which predates Windows by at least 10 years. My final refinements have more to do with Project V than with a strict GUI system though and that's the way it should be when you refactor. However, there is one thing that does bother me. I should not have had to try different implementations of GUI's. This forced me in doing step #1 which in turn forced me to do #2 as well whether I liked it or not.

With comic books, the failures aren't done anymore. If you offer a suggestion and try to get published, the editors and publishers will know what has been tried before and will not go for a second round. It's pointless. They already know what the outcome will be. There may be exceptions, but the general case holds. In programming, failures are thrown away and not remembered except for those who were directly involved.

I have one last item I want to talk about. For this one, we go back many years to when I lived in a basement apartment that if you called it a hell hole, it would have been a compliment. I was hardly ever there, so my time in that city was still a great deal of fun. I remember one time when my landlord was surprised the stove worked at all when I told him that you could only turn on one element at a time. If you know what kind of stove this is, you should be laughing your head off right now. In any case, one of the walls of the foundation had a crack. Water leaked in every time it rained. He had tried everything. He brought in any expert he could find. He even bought stuff from Japan. If there was anything on the market for filling cracks in foundations, he had tried it. Nothing worked.

He's explaining all this to me and I'm trying my best not to laugh. Actually, I think I did laugh and he said it was ok and that it was indeed a stupid situation. So he asks me if I know of anything that could fix this 100% no matter how crazy the idea. He's ready to try anything. I tell him that you could lift up the house off the foundation, break apart the section that has the crack, re-pour that section and bring the house back down. He looked at me with the most dumbfounded look I have ever seen. He said this was way too ridiculous. "What would the neighbours say?!", he exclaimed. This, from a man who owns a neon purple house. That has another story, but we won't go there. Needless to say, even though he said he didn't care what the solution was, he obviously did.

Yet, this isn't about sticking with what we are comfortable with. You could probably make that point, but that's not the goal here. No, what we're talking about here is that it is possible to replace the foundation without affecting the integrity of the rest of the structure. I don't think most people would even think of raising their house. I also don't think most people would think of replacing the foundation of their software. Further, I don't think it would be possible in most cases.

Why is it not possible? To understand this, you need to look at how connections are made when you build something. It doesn't matter if you're building software or something physical. This is a universal property. One kind of construction involves piling onto what's already there where there will always be one end that is not connected to anything. Even if you connect the open end, the new piece will have an open end and so on. This is commonly known as a hierarchy. Tree data structures are like this. No matter how many nodes you add, there will always be leaf nodes that aren't connected to anything. There are physical structures like this too. The great pyramids are like this. There is only ONE rock at the top that isn't connected to anything, but it still satisfies the criteria that you have to remove everything on top before getting to the foundation. Defensive walls and towers like the Romans built also had this property. If you tore down the foundation, the wall came crumbling down. It's one of the weaknesses of this structure. If the foundation goes, so does the rest.

The other structure is one where everything you install is meant to be connected on all ends. Phone lines and all telecommunication fibres share this feature. If you want to replace a segment, the entire network doesn't have to fail. Networks may indeed have leaf nodes, but it's not necessary. Most communications network have redundant paths, so that even if you use a hierarchy, it's not monolithic. Road networks are like this too. You can block a road and even though there will be congestion, at least some traffic still gets through or one can use an alternative route. Houses are also built like this. The floor joists are connected at both ends to the outside walls. The walls are connected to the roof. And the roof is connected to all four walls. Windows are connected on all sides and can be replaced. The foundation is likewise connected on all sides. The advantage of this kind of construction is that you can replace any part and it doesn't affect the rest of the structure.

Now let's look at our programming languages. A function is something that calls or invokes something else. It is definitely a tree structure where only existing functions can activate other functions. As such it is a building block of the first kind of construction where you need to have functions that don't call anything else. It's impossible to write software where you have functions that always call something else and does something significant. Returning right away is not using the abilities of the function itself and does not count. So every single paradigm and programming language that uses functions or methods lacks the ability to replace its foundation. Lisp, Java, C, C++, Pascal, BASIC, Erlang, Python, Smalltalk, Ruby, Oz, COBOL, FORTRAN, Modula-2/3, Haskell, JavaScript and more are all in that category. Include all stack based languages as well. All these languages have the built-in weakness that the foundation of the software you are building is the most critical part and must be built first, yet it must be constructed when you have the least amount of information.

The other category for software development is data flow. There are a few examples out there. Monads and arrows are such examples. Nodes in Lightwave and other 3D packages are other such examples. The Internet itself COULD be an example, but mostly everything online uses the request/reply paradigm. Overall, there aren't that many implementations that use this kind of construction.

Here's a quote from Alan Kay:

The Internet is like the human body. It’s replaced all of its atoms and bits at least twice since it started even though the Internet has never stopped working. Attacks on the ‘Net aren’t really attacks on the ‘Net, they’re attacks on machines on the ‘Net. Very few software systems, maybe none, are built in ways that sustain operation in spite of being continually rebuilt and continually growing.

- Alan Kay

Alan Kay noticed the feature of these two different kinds of construction, but does not understand why this is. He just thinks it's all about how you organise your software and designs. However, he is quite right that there are very few software systems built in the ways he describes.

Lift your software up and away from functions. Replace the parts that use functions, and then lower your software back onto its new foundation. Can you do it? Or is that too ridiculous? What will the neighbours think indeed!

(NOTE: This blog entry isn't about functions or data flow. Just in case anyone thought that, it's the wrong message.)

update:

Ok, I'll state it point blank. The title of this article is called Refactoring. The real world has already determined what kind of construction techniques are amenable to change and which are not. It's been known for thousands of years. And no amount of wishful thinking that software is somehow different to the rules of the Universe will make this fact untrue. You only use the first type of construction when you want something to stay there, as is, for a very long time. That's why the pyramids, water towers, lighthouses and defensive walls and towers are built like this. Sometimes, you can change the top (like adding weapons, archers and cauldrons of boiling tar to the top of a defensive wall), but the majority of the structure is not meant to change. And sometimes, none of it is meant to change.

Software isn't meant to stay static, yet most (all?) languages use the first type of construction. It doesn't matter what you use as building blocks of your software just as long as you make sure that the properties of what you are constructing are similar to the second type of construction.

The real world has already tackled most problems. Most of these have been tackled thousands of years ago. Remember that the Romans had a running water system that was unmatched until the 1950's. Unless we want to write the equivalent of the Great Pyramids where our software remains unchanged for thousands of years, then all we're doing is rehashing thousand year old ideas that are terrible when used in the wrong place. Refactoring has been done in almost every field you can think of. There are certain rules that cannot be broken. So far, programming is the textbook example of what happens when one uses the wrong kind of construction. Not sure what it says about the ones who thought up these languages in the first place though.

So to those who think we stand on the shoulders of giants, I'm sorry to inform you that those giants are standing on quicksand. There's a reason large software produces certain limitations.