Occam's razor

I am reading a book on philosophy. I am no philosopher. I am not good enough, I don't think. But I found this book by accident in a bookstore. I read the back cover, and decided to buy it, initially attracted by the title of the book: "Zeno and the Tortoise". That reminded me of "Godel Esther Bach", a book that I read so many times, trying to finish, always failing, that I picked it up.

It is a very good book for me, as I am rather hopeless in terms of understanding the subtleties in reasoning and the precise wordings that are prevalent in philosophy texts. This book is direct and simple, and it tells very good stories about the life and time of the philosophers the author chose to highlight. One of the philosophers is Occam, or Ockham. He is of course famous for "Occam's razor".

If there are two theories that explain a certain thing, the simpler one is to be preferred, other things being equal. I paraphrase, probably not terribly accurately. But hey, that is all I can get from the book with my philosophy-deficient mind.

When I was reading the little essay about this little saying, I was thinking, can this possibly be applied to software architecture, software design, and software implementation? And are we doing that at all? Sadly, after a few minutes, I have to conclude, from my experience, from my readings, and from talking to other people, that it is not practiced by software professionals. And I think I know why.

I believe in the elitist notion that most people don't know what they are doing and don't really care that is the case. So, I will discount most situations where simplistic solutions are deployed. The solutions don't even adequately handle the problems they mean to solve. So, they are not candidates for the razor. Let's pay attention to only people who do know what is going on.

In our society, our employment marketplace, I don't think it is monetarily advantageous for software architects, software designers and programmers to choose the simplest but adequate solution for their programming problems. For the designers and programmers, how can they learn some fashionable techniques and libraries and frameworks that are not exactly needed by the problem at hand, if they don't use these techniques, libraries, frameworks for the problem at hand anyway? For the architects, if the solution is simple, their employers might think that they could have done it themselves. Simplicity is not appreciated in the software industry. Complexity awes people. So, it is in the advantage of all involved to choose something that is much more complicated as long as it fulfills these desires: complex enough to fool the mostly non-software savvy managers for the architects, using whatever is fashionable for the designers and programmers so that they can learn all these things that they might need to know to land their next jobs.

So, I think the result is that we could have EJB around for so long without overwhelming opposition---I simply refuse to think that we did not have many people doubting the wisdom of such a thing, right from the beginning. And everybody happily assumes that to be enterprise worthy, they must deploy a full-blown J2EE container, even though it might only be a simple website that goes to the database to get some data to show as HTML.

And of course, I have been asked the same question for so many times, I probably should think of a boilerplate answer: but can your system handle 1000 times as much traffic? Well, can my stomach handle 1000 times as much food as I need to eat? If that question is irrelevant, what makes the previous question more relevant if there will never be 1000 times as much traffic?

Outlook on life

I just found the blog of the development manager of my team. I sort of scanned through the blog, not spending much time reading or thinking about the entries in the blog. That is how I read other people's blogs, quick and not terribly focused. The entries I scanned through are soft, flowing entries. Other personal blogs I had read seem to be like that too. My blogs are very different. My blogs are serious.

I write my blogs to crystallize thoughts. Perhaps that is the reason why nothing is soft in my blogs. Instead, they all have edges. Some sharper than the others, of course, but they all try to present some thoughts, whether I have been successful in conveying the thoughts or not.

I wonder whether that is the difference between my outlook on life and others'. My life is a series of hard-edged things, cushioned by the soft-living of everyday life. For other people, their lives might instead be everyday life punctuated by the unavoidable hard-edged work or studies.

I wonder.

Getting my life back

I have been tired for quite a while now. I am very effective at work, doing things that I did not know I could do. But then, when I got my book published, I was more astonished by that than most people. I am tired because I try to do my best at work, no slack, and especially not holding back on how and what I can help the company, the team, and the system.

The result is that I am always very tired after work. I don't feel like doing anything useful at all after dinner. And since I more or less ruined my stomach in these three years, I need some time to digest the dinner before going to bed, I need to do something to get through the three hours between my dinner and bedtime. What do I do in that time? Well, watching senseless TV. Of course. What do you expect?

Ever since I knew I would have to let go of the system, after the re-structuring of the team about one month ago, I felt a little bit better after work. I started to read books again. I started writing a little as well. After yesterday, when I knew about the fate of the team, I started to relax. As you can see, I actually have three entries in this blog today alone. That shows how relieved I am.

Now, I only need a few months, then maybe I should start writing another book.

Self-Interest

In these last weeks of a stage in the system I am relinquishing control of, I learned a lot about people surrounding it. From the investors, the executives, the other employees, and the members of the development team. I have to say some of them show a noble side that I did not know they had; but mostly, I saw terrible examples of blind self-interest.

It is amazing how people behave when even the smallest stake is in question. I hope the other people examining my actions and my words will say at least I tried to be helpful, and at least tried to be neutral. I can't say the same for most of the other people.

The members of the development team show surprising maturity, even though they are such young people. I believe their youth is actually one of the reasons why the other people thought of taking advantage of them. That is disgusting, of course. But, really, few people will come out smelling like the rose in this situation.

Let's just say I remember how these people behave. This is a small community; and we tend to need each other's help, one time or the other.

Still, it is so disheartening sometimes to know this side of people. Not pleasant at all.

Letting Go

Well, it looks like very soon I will have to relinquish control of the system I built up for three years now. With almost everything in place, I finally have the time to think about what letting this system go means to me.

I spent tons of energy, time, and efforts on this system. I worked 14, 16, 18 hour days, weekends, basically worked until I had to take days off to recuperate so that I could continue. Quite obviously, my health declined in these three years. I never imagine that my next pair of glasses is going to be bi-focal. And when I got sick, I got sick. A one-week cold for me a few years ago would take two weeks.

But I love every minute of development; the camaraderie of my wonderful team members. This is the best jelled team I have had in my career so far. I cherish all of it.

Actually, I thought I would have to keep doing this for another few years, building a great system. I probably would not be as busy, and my health would probably recover much better. I would not know now. I only know that letting it go is the best for me. It is probably best for the team too. I don't know.

This is not the first time I have to let go of a system I built. I am glad that every time that happened, the result had always been good for me. Not so good for the systems left behind, but then that is the essence of letting go: the fate must be decided by the people left behind, by the people who want to continue it, by the people who think they can do better.

I don't know whether I will be building bigger and better things. Actually, my dream is to own a company, so that I have no excuses if it does not do well. Besides, there is no shame in building beautiful small things.

So, so long. I will help in the coming months. But the torch has been passed, symbolically at least, from my hands. My hands are not failing, so they will be working on something else now.

Drive, part II

Well, I am at the end of my current employment. For once, I have nothing to do with it. Well, not directly, anyway. Like anything else, there are good things and bad things coming out of this event. One of the good things seems to be the energy I have on reading and writing again. I was used to reading a lot of stuff over a short period, technical and non-technical. I was also used to write a lot more than I have been for the last three years. I simply did not feel like writing that much at all for the last three years. And I was always exhausted after work too.

As like my previous employments, this soon-to-be over job has been very interesting. It has been very challenging; it has been very hard; and it has been very different from my jobs before this one.

There are some certainties about this job that is refreshing; for instance, I would have more or less no resources at all. Unlike my previous jobs, the power that be did not pretend they either knew software development or even cared about it. And they did not pretend they had any respect for the development people. This is refreshing; because I could simply write them all off this way, and came up with ways to succeed despite the obstacles. Very interesting situation.

I like to complain about people who don't know anything about software calling the shot for software development. This is not going to change in the near future, I don't think. Every time I talked to the executives of software or technology companies, I came out more convinced that power will always be in the hands of people who know very little about software development.

Anyway, I did learn a lot about software as a service and the challenges it imposes on software development. Through these three years, I argued with people about how it should be done. I argued with people about how production should be handled. And I argued with people about how testing should be done for this very interesting environment. I am convinced since very early on that a lot of conventional wisdom simply does not apply for software as a service.

Until I have a new job and become busy again, I am thinking about writing a series of articles on the journey I had from the beginning to the end of this saga.

But what has drive to do with it? Drive has something to do with it because throughout the three years, although there have been so many times that I could simply give up and walk away, instead, I simply worked harder to get it done. It is unfortunately it looks like it is for naught, and the domain knowledge I gained from it all going to be lost. But hey, nothing is guaranteed to be a success. I did have the drive the last three years.

I am very pleased by that.