The more you have, the more you should protect it

People care more about things they don't have enough of.

If you have tons and tons of money, you probably spend it less carefully than somebody who lives paycheck to paycheck. Water is more valued in California than in Florida where it rains all the time. Scarcity makes everyone think twice.

The same happens in software projects.

Teams usually get up in arms near the end, when budget is running out and deadlines are rapidily approaching. When both money and time are scarce, everyone starts thinking about them, and bend over backwards to fix the problem.

I think we can do better.

Precisely, it is at the beginning of the project where teams waste more; right when budgets are big enough and deadlines not yet in the horizon. Every decision seems inconsequential so nobody cares.

But this quickly catches up with the team. And just when everything should be coming together for a landing to successfully close the project, is when more and more pressure everyone feels from every angle.

The more you have, the harder you should work to avoid wasting it. You need to start looking at consequences right from the get go, not just when things get tight.

Statecharts and wireframes

I've always relied on wireframes to communicate the user interface requirements of a system. This is definitively a very good approach that helps everyone understand how an application is supposed to work.

It also has shortcomings; sometimes it's hard to communicate specific details without putting together wireframes showing all the different possibilities.

The process gets expensive really quick. The amount of time needed to put together these wireframes is definitively high compared to the time needed to use a statechart for the same purpose.

Here is a quick and high level statechart representing how this blog works as of today:

Obviously, with a statechart I'm limited to communicate behavior and not styles, or layout. It's a very good approach to tell the story of the interface of the system, however I feel it's very underused in the Industry.

Wireframes are still a more sexy way to solve the same problem. But they're also more expensive, slow to create, hard to maintain, and sometimes, difficult to decode. They generate a lot of waste when used incorrectly.

Statecharts are one possible answer to that.


Some people don't like to constantly jump from project to project. Sometimes I don't either. I guess you get tired of switching context; of having to learn everything again without the satisfaction of resting on past accomplishments.

Focusing on one project, or one type of project, or one vertical, or anything predictable and constant offers the opportunity of specialization, and that's a great thing. You definitively don't need to jump like crazy, but you also get the benefit of becoming really good at it.

That's a great thing, for sure.

But the same could also become boring. Even worse, it could lead to stagnation which could easily destroy a good team really quick.

Going from "cutting edge, awesome team" to "old, stuck in the past" doesn't take that long in the software world. Things change too fast for us to get too stuck in old ways, so anything that offers an outlet to try, improve, test, fail, start again is a blessing.

Remember this: your sharpest, more awesome engineers will never put up with the same project for too long. They understand they need to move on, to learn new things, to improve.

Preparing for the future

Even the more detailed and well-thought plan to finish your project can go awry at the very first turn. At that point is when all of us realize how bad we are at predicting the future, send a rant to our boss by email, and demand clients to stop asking questions we can't answer.

Yeah, I've been there myself. And unfortunatelly clients don't care and they keep asking things that I don't know today. Why in the world would they care about how long until we finish? Or how much are they going to have to pay us to get everything done?

Can they just trust me?

No they won't and they shouldn't have to.

Making a release plan is not about predicting the future, but about setting well-informed expectations with the client. We all understand that things may go wrong and render our plan invalid, so a good process will have to cover for this appropriately.

Here are a couple of things you want to keep in mind:

  1. Do not think of a release plan as something you set and forget. Keep in mind that every single decision you make has a direct implication on your release plan, which makes it a live, constantly updating plan instead of something you email the client on day 1 and then never bring up again.

  2. The key to control changes on your plan is constant communication with your client. Have them walk the walk with you so you can help each other make the right decisions for the project.

  3. Finally, a good release plan calls obstacles before they happen, plans to mitigate them, and proposes solutions for when nothing else can be done. Assuming everything will always go as expected is irresponsible and unrealistic.

You still won't be able to see the future, but you'll be using your present and past to better prepare for it.

Estimation is not about accuracy

Here is one thing I know about estimation in software development: It's not only hard, but it's also not about how accurate you can get.

Hey listen, I understand that the more time you spend in the Industry, the more experience will help you out coming up with estimates to develop features for a software application. That's clear, but that still will not make you a wizard that's able to see the future.

I've been related to software for more than 20 years, and foreseeing how long certain things will take is still as painful as day one. Sure, I'm probably doing better today, but I'm also still wrong most of the time.

But you know what? It doesn't matter.

If you put together all your estimates to develop a software product (and assuming you have enough experience to provide decent estimates), you can easily represent them in a bell curve: most of them will be pretty accurate, but you'll also have several outliers, both under and over the target.

From here on out is all about properly playing your cards: every time you come under, don't waste the remaining time; use it instead to offset those instances where you invariably came over. Whenever you are over, make sure you properly adjust deadlines and priorities. Communicate with your team and have them walk the journey with you.

There's no book out there, or course, or professor that can teach you how to get more accurate with your estimates for a good reason: you just can't change the fact that predicting is hard. But remember that it really doesn't matter. It's all the about the process, not the number itself.

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 against 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.