Articles Feed

Erlang and the OCP

by: eric | May 24th, 2008 | 0 comments »

OCP was defined in 1988 in Bertrand Meyer’s book “Object Oriented Software Construction” as follows:

Modules should be both open (for extension and adaptation) and closed (to avoid modification that affect clients)

Recently we had an issue in my office with our system which uses Rinda (a Ruby implentation of Linda) as a blackboard architecture. The architecture looks a little like this crude drawing.

This hides the OCP violation. The “rindlet,” our informal name for these subprocesses, actually removes the message from the blackboard. So if you send a message that looked like this [1, 2, 3] and one rindlet took it then no other rindlets can receive it. To repeat myself, this meant all messages had to have as their first data member the name of the rindlet they were sending the message too. This is bad. Adding another rindlet meant changing the client sending the message. Now to quote Agile Software Development: Principles, Patterns, and Practices [Martin 2003] An axis of change is an axis of change only if the changes actually occur. That is to say if only one rindlet cared about a message than this wouldn’t be an issue. When this became a problem was when more than one rindlet wanted the same message. Suddenly we have to send many otherwise identical messages to different rindlets. This is the heart of the OCP, the Server (in this case the one sending the messages), should be closed for implementation, but is not. In our case we changed the architecture to shield the server from those changes, and fixed the issue.

This brings me to Erlang and its message passing system. Last year I began playing with it, but lost interest as the difficulty of the syntax simply ruined the fun for me. I do know enough about it that when this issue came up in our ruby system, I was immediately reminded of Erlang’s message passing system. Specifically it has three methods [Armstrong 2007 pg. 134]:

spawn - Create a new concurrent process that evaluates a passed in Fun. The new process runs in parallel with the creating process.

Pid ! Message - Send a message to a Pid - returned by the previous spawn.

receive…end Receives a message that has been sent to a process.

On a cursory glance it appears we have the same issue since you must know the Pid of the process. Aha, but the command sending a message to the process actually created the process, and therein lies the difference. The blackboard architecture deliberately decouples the constantly running processes from messages, the messages are sent to the blackboard. The sender has no right to know about the constantly running process, and should not need to change to add another one. Erlang on the other hand spawns processes as if they were objects, and sends them messages. Sending messages, heck that’s what you do with an object too isn’t it? I don’t think creating an object and sending it messages is a violation of OCP, and neither is this. The sender can be extended without effecting clients. It turns out that Erlang does not intrinsically violate the OPC like I’d originally surmised, although like any other system I could easily create an architecture that did.

Promises Promises

by: eric | May 17th, 2008 | 0 comments »

“Under Promise, Over Deliver” (origin unknown)

“How are you going to get a reputation as a miracle worker if you tell the Captain the actual amount of time it will take?!?!” Scotty on Star Trek

I used to think the first statement was a just a more cynical restatement of the second, which is just a con job. Tell the boss you can’t have it done until Tuesday, finish on Friday, play golf Monday morning and deliver Monday afternoon. Everybody wins right? Except it’s fundamentally dishonest. Lately I’ve come to realize I do the first one every day, and I hope never do the second.

I have three step-children and I rarely promise them anything. It’s not because I’m a horrible father, but because a promise is a fundamentally special thing. I promised my wife I’d stay with her until the end of time, now that’s a promise. If I promise I know damn well I will do what I said, and I can’t have excuses. Now I’m naturally a very busy and easily distracted person so I know that if I promise too much, I’ll deliver a lot of disappointment. Instead I say “maybe” because it’s the honest answer. There is a huge difference between “I promise” and “I’ll try”, and I doubt “I’ll do my best” would have been an acceptable answer on my wedding day.

So what the heck does this have to do with development? I was thinking about iterations, and how the stories taken on are really a promise to the customer, but we don’t always treat them that way. A lot of teams, including at times our own unfortunately, instead Over Promise and Under Deliver. It’s usually done with the best of intentions because the customer wants more stuff done. You know what? My kids want to go to Dunkin Dounuts tomorrow, but I don’t know if I can take them so I won’t make a promise. We should look at our iterations the same way. I’m not talking about padding estimates like Scotty does, but what I’m talking about is avoid the traps of wishful-thinking when estimating stories. Specifically three things I see all the time.

• The Talk Down

The talk down usually happens when one or two team-members are out of sync with the rest of the group on the high side, but can also happen when the team’s points cover a range from small to large. Higher estimates mean higher risk and yet the lower estimates usually win this “battle.” There are two kinds of ways team members (and sometimes customers) encourage other developers down from their estimates, one good and one bad. I’ll illustrate with two stories where I was out of step with the group.

Right after I joined 8th Light we had a store that involved converting text to base64. I was inexperienced with Ruby and hadn’t done this before, so my estimate was higher than the others. At some point somebody said, “Eric that’s a method that’s built into ruby, it’s one method” and I sheepishly shrank my estimate. Hey I used to be a C++ programmer, cut me some slack! The point is this time being talked down made perfect sense. I didn’t know something, somebody told me the answer, and we fixed it.

Much more recently we had a story that involved showing the difference between two objects in the database. In this case I was again much higher than the group. I explained I had no idea how we would do this in a way that would satisfy the customer, but the team thought using the Unix diff tool on the already existing XML Output would be fine. With something feeling wrong in my gut I reluctantly brought down my estimate. A few minutes later Micah and I started on development, and discovered the problem. A few small changes to a product resulted in four pages of indecipherable XML differences. The story was scrapped, fortunately quickly before any time was invested in it.

Now what was different between the two times? In the first there was a concrete and clear way that my estimate was wrong. Yea! In the second there was still an icky feeling in my gut, yet I budged. Why? Because I don’t want to hold up my team, I don’t want to look stupid, and most importantly I failed to articulate my concerns with the approach given. You see for years I worked with InstallShield Developer, and for a while now they’ve saved their file format for projects as XML. But when two people attempted to work on the same file, then merge, it was almost always a nightmare, and this was with tools that just did diffing like Araxis Merge. Our quickly done tool to solve an immediate business need had little chance of success, but I was uncomfortable saying so. The moral: Don’t let yourself be talked down unless you really feel talked down. The team wasn’t wrong for stating how they felt, I was wrong for failing to articulate the issues I had.

• The extra points

Occasionally as a team you really want to impress the customer, and they’re in a hurry. So maybe you take on a few extra points. I don’t feel this needs much explanation, don’t “hope” you can get it all done. Use your velocity, trust your estimates, and KNOW you’ll get it all done.

• The “Ambitious” Iteration

Sometimes your iteration feels just…off. You’ve taken on the same number of points as the previous iteration, but it feels in your gut like it’s too much. Now this is where the promise kicks in. Would you promise your loved ones something that in your gut you just didn’t feel like you could deilver? Than don’t do it to your customer. When the iteration feels ambitious try to put it in concrete terms, maybe you’ve been the victim of the “talk down.”

Remember a promise is a very important, even sacred, thing. It should not be taken on unless you are absolutely sure you can do it. Try saying to yourself before an iteration, “We promise to get all this done.” If that causes a shiver to go down your spine there’s a good chance you really hope you’ll get it all done, and maybe should take a bit off the board rather than be proven right later.

Wake up and code!

by: paul | May 8th, 2008 | 1 comments »

The other day, I was with my team at an interview for an internship. After we had asked the candidate some questions, he started to reciprocate, asking each one of us a little about our development past. Every one of the developers stories went something like, I was at the wrong job, and had to get out. The candidate listened carefully to each story, sat for a minute, then asked the obvious perfect question, “What makes the right job?”

I heard responses like “Waking up in the morning and being excited to work, rather than counting the days until the weekend.” The reason this struck me as interesting was only when I reflected back to why I loved computers and programming in the beginning. It was all about the problem. I went to college, so I could join the CIA or some think tank which wrote software which monitored and defeated the enemies entire world. About every developer I went to college with got into computer science with some similar grandiose notion. Most of them were gamers that wanted to work on the next big game. Yet today, I know no developer who works on games, and I don’t work for a think tank. I know lots of developers who are more than qualified to do it, but choose not to. So, how does this relate to the right job question?

The answers about the right job question had nothing to do with the problem set being solved either. Nothing to do with WHAT applications were being written, but the culture and with whom they are being written. I think this is because each problem set worth application development proposes unique and interesting problems for a developer to solve. I have never been on a project which didn’t constantly keep me on my toes as far as problems to be solved. Even if the business domain is a bit bland, the development domain isn’t. I have seen developers to do lists get bigger and bigger from day one on a project, and never shrink. This has nothing to do with laziness, quite the opposite, it has to do with an insatiable drive to make things better than they are.

As a developer, my problem set isn’t the business/science problems I am solving, even though that might be interesting in itself. My problem set is development itself, the different patterns/practices I use to solve the world’s [software] problems. It is like many art forms where the beauty and creativity exists in the process of creation rather than the results. I am sure you could have asked Pablo Picasso to paint something he didn’t have any interest in, and he would have been passionate about it and done a wonderful job. I suspect it is because the importance is in the painting process and the choices you make during each step. How he chooses to depict the subject is more interesting more than the nature of the subject itself. I find the same true in development. The thought that goes into the different development choices I make on a daily basis is the part that drives me to love development.

Having the right results is only part of the equation (an essential part though). When I started my path as a developer craftsman, I learned the WHAT in applications is not as important as all the other variables. I suspect some of the other members on my team would agree, based on their answers to the right job question. Being part of a company that values the software for its own ends and spends the time and attention to do it right is a privilege to me. To me, that is the definition of the right job. I enjoy knowing my software will be used. Everything I write is valuable to the company for its longevity and success. It takes people who are similar in values for it to work, but it makes the work fun. It makes me wake up before my alarm, rather than snoozing.

Chirb Presentation

by: eric | May 6th, 2008 | 0 comments »

I gave a Chirb presentation last night on RubyCocoa, which went reasonably well. The slides, the working versions, are here. Unfortunately the images do not show in Safari, so you may want to use Firefox.

####