Thoughts about OCL - The Object Constraint Language

Right now I'm taking the Software Architecture and Design class (CS6310) for my graduate degree. Specifically for the last couple of weeks, we have been looking into OCL (Object Constraint Language).

Although all the time I spent studying UML back while in college, and even during all these years that I have used UML, OCL has been completely new to me. For some reason I never heard about it before (or maybe I did, but didn't pay attention.)

The thing is that I've found it fascinating. OCL is a formal language to describe expressions on UML models. You can think of it as a tool to write invariants, pre, and post-conditions for objects and operations in your model.

The first thought I have about OCL is that I already had the problem it solves covered. Anytime I've wanted to describe constraints, I've simply used regular language (either Spanish or English, depending on the audience.) Something like "If this object is blue, then that other object has to be red" has been usually good enough. OCL formalizes this, which is cool, but then forces everyone to understand it.

This leads to my second thought: OCL is something new that you need to learn. Not only the person who is creating the design, but also the people who are going to be reading it. I think this is a huge barrier for OCL. It doesn't matter that I can write cool preconditions in OCL if nobody is able to read them.

The third thing is that existing programing languages sort of do the same as OCL. Why not to specify constraints using pseudocode or near-compiling-code in the language of your choice? How would that be different? Having looked at OCL's syntax, I can see how it's compact and efficient for its task, but I still feel it will be way better to write some quick Java than to learn a new language from scratch.

Finally, somebody on my team noticed that writing OCL feels a whole lot like writing unit tests. That's cool and powerful, but it also makes OCL feel unnecessary and overlapping with already established tools.

There was a poll in my class asking how many people have used OCL in their regular jobs. So far, 41 people have answered no. Nobody has said yes yet.

OCL is not new. The fact that it hasn't been too popular might have something to do with my thoughts above. Would I use it after this class? I'm definitively incorporating some of its syntax sugar into my daily work. However, I don't think I will never do OCL formally.

As always, welcome anything new that can help with your work. Even if that means taking bit and pieces from here and there. OCL has definitively a lot to offer, so instead of completely shutting down the door because nobody else cares, take a look and decide for yourself.

Don't do functional teams

There are multiple ways to organize a development team. You need to take into account your business and the type of work you are doing. Every company is different so is every manager.

So I'm not here to tell you how to organize your team (I couldn't possible do that). I'm here to warn you againts the easy way out: functional teams.

This is the most common "organization" I've seen: A database team, a server-side team, a client-side team, a security team...

You get the idea.

I'll let you do your homework about functional teams. Brighter and more experienced people in the industry have talked extensibly about this, so I'm not going to repeat everything said already. I'll do say, however, that they just don't work as you might expect.

If you are working in an application that requires more than one of these teams collaborating together, any virtual walls between them are going to hurt more than help. Functional teams create enough barriers to make your job way more difficult than necessary. It's a perpetual "You can't do that because they have to do it or approve it".

Here it is in the words of Martin Fowler. I'm sure he knows what he's talking about.

Although it seems simple, even obvious, don't fall in the trap. Based on the work you want to do, find a different way.

Back to school if you can

I spent a lot of time over the last few weeks studying for the class I was taking this semester: Advanced Operating Systems. The class, albeit fascinating, was extremely challenging.

The good news is that I learned a ton. It's incredible how many things directly related to the way operating systems work I was able to apply to several of the projects I have going on right now: from caching strategies, to load balancing, threads, and barriers.

This experience has been incredibly humbling. Even things I thought I knew I've been able to look from a totally different perspective. The amount of stuff I've learn in such a short period of time is amazing.

If you have the opportunity of going back to school, please do it. You might have to pay for it, but it's hard to justify not doing it from the knowledge perspective.


We are trying to get more "remote" than what we currently are. I think it's a very sound strategy for anyone that's part of the software industry, specially if you'd like access to the best team out there you can get.

Lot of folks don't believe in a remote culture, and they keep shouting that not being next to each other leads to an inefficient work environment.

I don't believe that's true. I think it'll probably be more inefficient than having the same team collocated, but it doesn't need to be inefficient at all.

Keep in mind that here we are talking about the same team. If you want to hire from outside that circle, the equation changes really quick: a remote environment with access to the best talent will certainly outperform a collocated one with a limited pool of people to choose from.

So if you have a team that already works from the office, and if you believe that that team will probably be more inefficient working from home, is it a good idea to make them work remotely?

If you want to grow that team, the answer is yes. Even if you aren't planning to add anyone else in the coming years, somebody will probably leave and you'll have to fill that void, and having your whole team working from one place while plugging holes with remote people is always a bad strategy.

Remote work is not just a fad that will go away. Companies that don't embrace it will have to compensate giving something else to stay competitive. The question becomes how much are you willing to pay when the time comes.

Shifted Up

I thought it was time to make the move and name by blog something different than my own personal name. People always had a hard time spelling the URL which is the one I've been using forever.

Don't ask me why I chose "Shifted Up", but I like it. I already moved everything to the new domain and all the old references redirect appropriately.

Now it comes a long wait until the whole Internet (Google) recognizes the new domain.

I've tested a lot before pulling the plug, but I wouldn't be surprise if something breaks now that the new site is up and running. Please, if you see anything broken, let me know.

About multi-functional teams

Some people really like the idea of having multi-functional teams. (Anyone from the agile work will probably tell you this is, as much as possible, the way to go.) A team where everyone knows how to do anything that needs to get done in order to build a product.

Some people hire specialists instead. Designers, front-end developers, back-end developers, user experience specialists, quality assurance, copywriters, etc.

A friend from Dominican Republic asked me whether I prefer a multi-functional team or a more conventional team where everyone is sort of an specialist doing specific things.

My answer is that it depends. More specificly, I think you should strive for getting as much as you can from both approaches.

First of all, for a complex field like software development, I think it's extremely hard to find a team that's completely multi-functional. Sure, you can have a designer that knows how to code HTML pages, and a front-end developer that also knows database design, but the more complex it gets, the more "specialized" you'll have to get to find the required expertise.

(I don't know about you, but I'd rather have a security specialist taking care of my bank's system. Nothing against designers, but I prefer a person that lives and breathes security to be in charge of that.)

On the other hand, having a team where everyone can do it all is extremely versatile and flexible. Anyone can pick up the slack of another person and the overall productivity of the team will be really high. The number of possible bottlenecks by having someone busy is reduced because anyone can work on anything at any time. This is really cool.

As always, I think there has to be certain balance.

Identify the things you have to do and determine whether they deserve specific knowledge. If you are working on a simple website, you might try to push for more multi-functionality, but if you need more complicated and specific behaviors, you might need to look into someone whose focused only on that. Sometimes, you don't even need specialists as part of your team, and you can get away using them as a consulting role. It really depends how much you need from them.

In my experience, complex and long applications require more specific specialities in the team, while simpler, shorter projects can get away with the do-it-all type of person.

The last thing I'd say, is that no matter where you end, always try to be as multi-functional as you can. Even if you have 5 people with complete separate responsibilities, make sure they understand what a "Team" concept is and how it functions. The more they help each other, the better your journey will be.

Developers, testers, and the communication between them

You know something that developers are really good at? Blaming other developers. Another thing? Fighting with quality assurance people.

Joking aside, I think is human nature to be defensive when somebody else holds a title that allows them to review and approve your work. (I personally struggled with that idea for a long time, but finally made peace with it.)

Having a QA person dedicated to make sure your work goes out the door flawlessly is a blessing. These are people that dedicate every hour of their working days to give you all the information you need to correct your own mistakes. We should be eternally grateful about that. Every single day.

Here is the catch: if you want the good stuff that comes from having a QA team dedicated to you, you need to make certain adjustments and learn to work with them.

More than anything else, I'm thinking about communication: a good team fusions developers and testers in one, not separate silos that can't talk to each other (or can, but it's extremely cumbersome and inefficient.)

When organizing a team, this is a good place to look at: How to maximize the information that's shared between these people? How to make sure knowledge is promptly disseminated and acted on by both sides? How can you get everyone to communicate efficiently and effectively?

(This is one area where I think remote work helps a lot. Being able to talk directly to people is a double-sided sword when discussing tasks to be implemented. Although you are maximizing efficiency in the short term, you are putting a lot of pressure in everyone's memory three days from now when trying to remember that same conversation. Working remotely forces everyone to over communicate in writing.)

I'm not sure I'll ever get every single developer that works with me to love our QA team, but I'll try. For now, I'm happy seeing how much progress they are making communicating with each other.

P.S. If you are a developer, and you happen to work with a person that regularly tests your code, stand up from your desk and tell him/her how much you appreciate it (an email will also work.)

Computer Science Courses that Don't Exist, But Should

Really enjoyed this short post from James. He nailed it with his 5 courses that don't exist but should. I wanted to add another three to the list:

CSCI 1700: Naming things: An introduction to the fascinating world of naming conventions and the use of acronyms. Discover how every language does things differently, and learn 1,001 abbreviations that you'll need to know to understand people's code.

CSCI 1810: There's no such thing as a 5-minute task: A journey through the world of estimating software development tasks where you'll learn than 5 minutes is not enough time to do anything valuable (so you can stop using it right away).

CSCI 1870: Everyone's code is equally bad: Discover how bad your own code is when you read it after a week of writing it. Learn how to respect other developers and understand the value of collaboration over the illusion of being right when you aren't.

To manage technical debt all we need is discipline

I've written before about technical debt. I'd like to write some more about it, but this time about the way we try to keep it in line.

I've found that working on technical debt is not (and probably will never be) a sexy topic to talk or think about. People don't necessarily see it as something important, or at least not as important as everything else they are scheduled to work on. This is why working on technical debt is more about discipline and being consistent than anything else.

(Of course, there's no single company, or blog post, or cool kid that will tell you that they don't care, or don't do anything about it, or don't have a mastermind plan to keep debt low. The truth is very different: most people talk about it but just a few do something valuable.)

You can probably rally your time around the idea. They'll see the importance, they'll get motivated, they'll do it for the first time, maybe a second time as well. But by the third time around, something more important will be on the line. It only takes postponing it one time for the entire process to come down and collapse.

As I said, like taking the trash out, managing debt is not sexy but very important. You have to be disciplined about it. Motivation helps, but you won't find it frequently enough.

In one of our teams we started the following cadence:

  • One Thursday every two weeks is fully dedicated to work on technical debt. Not negotiable.

  • As developers, we own the debt backlog and we keep it updated along the week with everything we find we'd like to change.

  • When adding an issue to the backlog, we classify it using one of the following criteria: easy, medium, large, insane.

  • When Thursday comes around, we meet for 30 minutes, prioritize the backlog, and decide what will get done.

  • At the end of the day we update the backlog with our progress, and move on until next time.

(One thing I'd like to introduce to close the day is a code review session before updating the backlog. I'm waiting to establish a better rhythm with the team; one change at a time.)

We've been doing this for several weeks now. Not perfect (I'm still fighting with the team the idea of whether this is really important or not) but at least very consistently. I think that's the key: do it enough times and it'll become second nature and an indispensable part of our process.

I'm sure you are doing something different, and I'd love to hear about it. How does it get done in your organization? Let me know.

Better to look after the product, not my time

Sometimes I feel the urge to go back and negotiate more favorable terms for me or my team. (I'm talking about features in a software system, not money.)

The client wants to implement something. Sometimes is better for us if they want fewer things. Maybe if we do some of them different will also save us time. My reaction is to always stand up, and try to change the client's mind.

That's not necessarily bad, but only when we are thinking about the final product, and not our own time. When I'm acting as the client, it really makes me mad having people trying to change my mind just because it's more convenient for them.

There's a huge difference in the conversation when you approach it from the product's perspective, and not your own self(ish) interest.

I'm teaching myself to suck it up and live up to the expectations that were put on me and my team. Unless I have a valid reason to change something, I'm pushing forward to deliver it all. I want to always shoot for more, not less.