El bucle de Tiempo (The Time loop)

This is a small piece I entered into a (VERY) short stories writing contest, sponsored by a Mexican bookstore (El Péndulo), some time ago. The theme was A conversation with myself 25 years older and it was limited to 1,000 characters, including spaces and punctuation. Following, is my translation into English (although I think this translations does not comply with the 1,000 character limit, I didn’t count).

 

  • Una mañana estaba sentado en un parque, cuando vi a alguien que creí reconocer. Perdón, señor, pero me es muy familiar. ¿Somos parientes? No exactamente. Soy tú, 25 años mayor. Y estoy aquí para contestarte solo una pregunta, la que quieras, aunque temo que sé cuál va a ser. Normalmente, me hubiera reído de él, pero por alguna razón, le creí. Me puse nervioso. Él sabía todo acerca de mis próximos 25 años, pero solamente podía hacer una pregunta. Por fin me decidí: ¿Cómo es mi vida en los próximos 25 años? No pudo ocultar su frustración. Él había preguntado lo mismo 25 años antes. Me dijo: Tus siguientes 25 años serán buenos, tu vida seguirá siendo igual, pero pudo ser espectacular. Y este momento era crucial. Podrías haberme preguntado cuándo había que arriesgarse, pero no lo hiciste. Lástima. Nos despedimos y me quedé con una extraña anticipación de este momento en 25 años, como la de quien vuelve a ver una película, esperando que esta vez, el personaje no cometa el mismo error.

 

  • The Time Loop One morning I was sitting in a park, when I saw someone I thought I recognized. Sorry, sir, but you very familiar to me. Are we related? Not quite. I am yourself, 25 years older. and I’m here to answer just one question for you, although I fear I know what you’ll ask. Normally, I would have laughed at him, but for some reason, I believed him. I got nervous. He knew everything about my next 25 years, but I could only ask one question. At last I decided: How will my life be for the next 25 years? He could not hide his frustration. He had asked the same thing 25 years earlier. He said Your next 25 years will be good, your life will remain the same, but it could be spectacular. And this moment was crucial. You could have asked me when to take major risks, but you did not. Pity. We said goodbye and I stayed with a strange anticipation for this moment 25 years forward, like the one who sees a movie again, hoping that this time, the main character does not make the same mistake.
Advertisements

So your Web API is not really RESTful. Is it the end of the world?

Short answer, in my opinion, no.

Let me explain. I do think striving to design a RESTful API is a good thing. The REST architectural style has some great features, but the real world business needs are not always easy to fit into them.

I find that the process involved in trying to fit your business model into REST architecture is valuable in itself, even if the end result is not pure REST. It makes you think about it in a different way, from a different perspective. You may even discover new services you can offer. It makes my think about what my dad always said, Thing will never be perfect, but they will always be perfectible.

One of the things I find more difficult is that REST APIs should be discoverable and should not need any documentation to speak of. I mean, when we are designing and creating a new service, most people out there will not know about it, what it is for, what you can do with it, etc. So, you need to create some documentation anyway, why not fully document the API, provide examples and even a mock service.

Design is always just an approximation

When you are designing a database schema for an application, you will only be able to achieve an approximation of an ideal solution.

You will have to deal with incomplete specifications, with changing functionalities with applications that were there before and have a less than ideal design and all sorts of factors that will make your job very difficult, at best, and impossible at worst.

Whenever you are designing a new schema for a new application, you will be dealing with incomplete specifications. And this is not because the guys designing the new product or functionality are dumb. Most of the times, when you and your company are creating a new product or service, the operation conditions are not well known. As a consequence of this, it is almost certain that the functionalities that you originally designed for will change. You will also need to interact with systems that are already in place and this interaction will probably be difficult, because the other application was almost surely, not designed for it.

How can you deal with these problems and be able to do an adequate job? These are my recommendations:

  • Get involved with the business side of you company to better understand the design process of the people who are creating this new product. And do it as early as possible.
  • Familiarize yourself with how all you company’s systems work, so you can develop a better feel for how the new product fits in the big picture and, even, get a feel for how all new applications and products can be designed and created.
  • Create a kind of meta-design for all the data from all the applications; where should each piece of information about each different entity with whom your company interacts reside. Do not worry if you are not able to change current schemas to conform to this meta-design. At some point in the future, you are likely to redesign parts of older applications and, if the meta-design is present during your redesign process, you will be able to reach a better approximation.
  • Discuss with other areas where does the unique value of your company resides. It is common in young companies to build everything from scratch. As time goes by some pieces, almost surely the ones that do not represent the core value offered by the company can be replaced with commercial products.

So, to summarize, your job as a designer is never complete, but do not despair. Also, you will need to become less of a techie and more of a business person in order to do a better job. I know this may sound like something you will never like, but give it time.

My 2 bits on Bitcoin

I have been intrigued by the Blockchain and Bitcoin technologies since it came to the public sphere. I have been trying to understand the phenomenon, more so than the underlying technology.and these are my thoughts on the matter.

Let me say up front, I’m no expert in economy nor in the particulars of the Blockchain fundamentals. But anyway, here it goes.

I think the Bitcoin/Blockchain phenomenon has some brilliant aspects and some that I think will impede its adoption as a currency as we know it (like the Dollar or the Euro).

The Blockchain technology is brilliant. It provides a way to authenticate and avoid repudiation of transactions, all this without a central authority.

This lack of a central authority has attracted people who believe in free commerce, like criminals, drug dealers and also, perfectly law abiding people.

But thi lack of central authority has made it difficult for governments to oversee and tax transactions. This is part of the allure to some, but I think it will also mean it will never be adopted as a payment method by any country.

In my opinion, as much as we hate taxes, they represent the only way a nation state can survive and provide the basic public services we expect. Taxes pay for the roads we travel on, the water and sewage systems, the healthcare systems and much more.

Another thing that a central authority provides is confidence. It is the ultimate guarantee that my money will have value. A Bitcoin transaction may be impossible to repudiate, but without the threat of the force of the state, there is nothing that would force the counterparty of my transaction to honor their word.

So, as much as I admire the ttechnology behind Blockchain, I doubt that Bitcoin will succeed as a currency.

What’s in a name?

Please allow me to quote Shakespeare in this humble blog entry.

The act of naming things is very important, much more than you might think.

Many companies are constantly thinking of new products, new ways of doing things. Since these are new, people out there have never seen them or something like it. You need to find a name that is self-explanatory and is also sexy and commercially sound. I suppose this is one of the reasons companies sometimes use codenames (Microsoft does it all the time).

And naming is important internally too. Suppose you have a group of sales reps. You need to classify them into Sellers and Non Sellers and the criteria depends on how long it has been since their last sale. It is very common to have come people define a Non Seller as a rep who hasn’t sold an item in 2 weeks, and someone else defining it as not having a sale in 1 month. These situations can lead to massive misunderstandings with dire consequences.

So, be very mindful of the process of naming in your company. Try to reach consensus early, maybe not in the final name, but in the code name at least. It will save you a lot of headaches down the road.

What it means to be a Data Architect

In my opinion, a Data Architect embodies the following characteristics:

  • Deep and wide knowledge: The Data Architect needs to have a deep understanding of the whole organization. Rather than deep technical knowledge (although I’m sure most of them are seasoned SQL developers), she needs to understand how the organization works, what does it produce, what are the future plans, etc. in order to be able to make useful decisions on how to architect the data storage.
  • Ability to communicate: He needs to be able to talk to business people and understand their ideas. From there, he has to come up with a very general map of the solution. Then, he has to be able to communicate this general view to the developers, who will fill in the details of the implementation.
  • Confidence: Usually, Data Architects are some of the persons who have been longer in the organization. So, most people, even their bosses, will turn to them for advice. It is not uncommon to find them being part of steering committees, where everyone else is much higher in the organization.
  • Be the Enforcer: Most organizations should have a Best Practices manual that sets rules for naming convention, general coding practices, documentation, etc. It is common that the person who approves new code for compliance to these best practices is the Data Architect. And if this is the case, she will have to stand firm against developers who are in a rush to get their solutions to Production.

I’m sure many of you Data Architects out there can think of other characteristics. Please feel free to share them in the Comments section.

 

Growing pains

I have been in my current job for several years and I have been part of the transformation of the company from a small, almost mom & pop, business, into a corporation.

The process has been difficult. Old habits die hard. But, at the same time, it has been very rewarding. It is the first time I have been involved in creating the processes by which the company will operate. This means being able to envision the way we want things to work and then, inventing the processes, the controls, the roles and their interactions that will be needed to operate the company.

It is sometimes very frustrating to find there is no established way to do anything. But, this very fact allows you to be creative and imagine the way you think is the best for the company.

It allows and demands from you to grow along with the company and be able to change your views radically. You are constantly re-thinking the way to do everything.

I think I have been very lucky in the fact that I have been with the company during the growth process and I would definitely recommend it if you ever have a similar opportunity.