Thursday, September 13, 2012

Difference between agile and Agile

    The Agile manifesto was the common ground found by a (heterogeneous) group of 17 software development experts (who now call themselves The Agile Alliance) with different backgrounds that included Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming. They all agreed, in spite of their dramatically different points of view,  on a list of 12 base principles of how software development should be managed. This 12 point list is now known as the Manifesto for Agile Software Development.

    1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    1. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
    1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    1. Business people and developers must work together daily throughout the project.
    1. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    1. Working software is the primary measure of progress.
    1. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    1. Continuous attention to technical excellence and good design enhances agility.
    2. Simplicity--the art of maximizing the amount of work not done--is essential.
    3. The best architectures, requirements, and designs emerge from self-organizing teams.
    4. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    These 12 principles are based on 4 essential guidelines:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    Please note that this guidelines are presented as a dichotomy (which is by itself controversial), this means that all Agile project must mainly align to the left side of this list (the Light side of the Force you might say?).
    So in simple words; you are not on an Agile project if you value documentation over working software or you value more your plan that responding to change. Now let me clear something up before some of you start rising an eyebrow in disapproval... It’s perfectly ok to value comprehensive documentation over working software or processes and tools over individuals and interactions, some projects have to work that way, it all depends on the nature of the project, which brings up the question:

    Is Agile the approach the best someone could have on a software developments nowadays?
    The answer: NO!!, it depends on the nature of the project, Agile is not going to work on all projects.

    Why agile is not the same as Agile.

    There has been a lot of confusion lately caused by the abuse and misuse of the term Agile. So let’s clear out what is strictly Agile and what isn't.  Just remember the essential principles and why the manifesto was created for in the first place. People can call their approach agile (notice the lower case "a") which can mean whatever they want, this is the main source of all the confusion regarding Agile Development. Agile is by itself an adjective that describes something flexible that reacts fast. That fact plus all the buzz Agile Development (notice the capital “A”) has generated recently has caused people to indiscriminately use it to describe their project, design, coding, management, testing and even documentation techniques or methodologies as "agile" when they believe that they are "fast" or "faster than..." by whatever arbitrary standard they can think of, so you can  append "agile" to anything you want to, just to make it sound trendy and cooler;

    The "agile" incremental beer drinking technique (I know a couple of guys I work with how are experts on this).

     Agile is just a set or principles that are open to interpretation. There is no methodology set on stone you can follow or any set of tools you could use. This is a good thing if you think about how flexible it can be. You can hypothetically allocate virtually any kind of project within this frame and improve is greatly, but the down side is that you can easily get lost in the path that doesn’t have any barriers on the sides that delimit it clearly. This explains why you can buy 2 different Agile books and still get contradicting opinions on the same subjects.

    So just to wrap things up;

    • Agile: Is a set of 12 principles for software development aimed to increase productivity by prioritizing activities that add real value to the project and to the deliverables. Agile is leveraged by an incremental and iterative approach.  It is a great way to manage projects in which the requirements are not completely defined by the start (like most of the projects we engage on at DMT). It can be risky to follow it on project that demand requirements to be perfectly defined upfront or that requires a very detailed change process (basically any project that by nature requires you to value any of the guidelines right side).
    • “agile”: Anything that moves quickly.

Thursday, April 26, 2012

In a Country not so far, far away

Everyone working in any IT market with a serious enough  job knows for a fact that the all time champion of outsourcing is by all means the exotic sub continent of India. India has the great advantage, besides the currency exchange differences between USD and Rupiahs, that they have a this huge population of well trained, English speaking people (its entire population is around 900+ million that's 9 times Mexico's ). This makes them the worlds largest talent pool (second after China) for all USA based operations. India also embraces a self improving and study culture that most people adhere to. They also are perceived as a more westernized culture compared to Korea or China which is a bonus for any USA organization outsourcing operations with them because that turns communication flow smoother. USA businesses prefer them for all those reasons and this preference is the cause of the great economic growth they have been experiencing in the last 2 decades.

Moving operations offshore is no easy task as you surely can imagine. It requires infrastructure, process definitions, certifications and a whole universe of mechanisms and bureaucratic leaps of faith for the USA based customer to be able to supervise all relevant activities. Besides that, for IT related outsourcing, specifically for that related to software development of any level,  there is also the matter of establishing effective communication with the offshore team. That communication is always going to be slower and more inefficient than between local-native software developers due to cultural and language differences. This communication overhead adds up to the cost of the total operation along with the required investments on infrastructure (Bandwidth, phone lines, conference  calls, etc). There also needs to be more supervision so this is usually covered by adding onshore managers to serve as communication bridges between onshore and offshore team members. Some times it is worth for someone on the offshore team  to visit the customer so that adds traveling expenses. Add all up and the resulting  additional cost is know as TEC (Total Engagement Cost) which means the additional money customers need to pay to afford an offshore team that they otherwise wouldn't pay if they had only onshore people.

The pretty part of offshore is that even with the TEC, the total operation cost is still lower than a onshore team this to the difference in per-engineer net costs. For instance, consider this data:

Avg. Annual Salary (Local Currency)
Avg. Annual  Salary (USD - 4/25/2012)
Java Web Developer - Senior
$744,985 INR
$14,190 USD
Java Web Developer - Senior
$242,208 MXP
$18,439 USD
Java Web Developer - Senior
$87,638 USD
$87,638 USD

In operation terms this means that you can have 6 Indian engineers for the same cost as 1 USA engineer or 4 Mexican engineers. So its really obvious why US companies move operations offshore. If you noticed on the above data India is roughly 25% to 30% cheaper than Mexico is, which is one of the main reasons you must certainly work with someone who gets his paycheck from iGate Patni, Tata or Infosys.

Now that's not the whole story, remember the TEC? Well that's a big game changer because according to experts TEC on India is about 25% higher than in Mexico an South-America which levels the playing ground for those of us who live here.
There is where the Nearshore marketing term appears into scene.

What's the difference between Offshore and Nearshore? Easy… a smaller TEC and also time zone alignment (which is not always a good thing as we'll discuss it later) . Another good thing about it has to do with travels. One on the requirements of any offshore manager is to visit its offshore team at least one time a year. This helps him connect with the team and boost their morale. Also it is beneficial to bring someone on the offshore team to work onshore from time to time because of the same reasons specially if there is some delicate matter at hand (alpha testing, new development, requirement gathering for a redesign, etc). Given that premise, consider that commercial flights to Bangalore take 22hr ( plus the additional adjustment time) while a short trip from Connecticut to Aguascalientes or Guadalajara is roughly 3hrs to 5hrs, to Rio de Janeiro is around 8 to 10, so that's another perk you get from having a closer (nearer in this case) team. Another aspect to take into account is that Mexico has a lower turnover rate (10%) compared to India (almost 40%) this to the fact that the Mexican labor market is not as harsh as that of India also working conditions are more endurable at medium term, specially those that have to do with working schedule.. There is also the communication matter, What country (excluding Canada) is more culturally aligned to US that good o'l friendly neighbor Mexico?

Then there is the productivity loss associated to every offshore project. US based companies calculate that the productivity loss with India based teams is around 25% so for they to get the same productivity of 4 US based developers they need to have and 5 Indian developers, While in Mexico and South America the productivity is around 10% so you can basically keep teams the same size than those base d on US. This productivity loss is generally a by product of communication overhead and time zone differences.

Considering the previous this is what customers get when you decide to get a Mexican development team to do the bit gardening:

  • Cheaper phone calls.
  • Less communication overhead.
  • Cheaper and more accessible trips.
  • Shorter Trips.
  • You can get anyone on your team onsite almost the same day.
  • Less turnover.
  • Less productivity loss.
  • Working in the same time zone without risking team burnout.

So why is India then still the undisputed master of IT? Well it has to do with the fact that Mexico and South America are in the newer in this market (20 years average) and also that the English speaking population is significantly smaller than that of India so on-boarding processes are slower. Also the Indian government has created great incentives and bureau shortcuts to ensured that the IT Industry blossoms like a white lotus (made of cash), while in Mexico, for instance, there is no real support for the IT industry and also historically Mexico has never been a start-up friendly place.

I work with lots of people located on Bangalore and Mumbai, they are exactly as anyone would expected a development team from any place on the world to be. The older and experienced ones are walking encyclopedias with great talent and insight, the newer ones are not that savvy but filled with excitement and willingness to learn, and interns are just keyboard operators awaiting their moment to shine. The same happens here, exactly the same. Also companies here follow the same kind of best practices as any offshore service provider in the world, this practices are in fact enforced by the US companies that hire the services (ITIL, CMMI, SAS70, SOX404, etc) so there is really isn't way of not having them.

The only difference I've been able to perceive is that we are willing to take more risks than they are, I guess the job market pressure there is intense, or so have some friends located there told me so, they need to be very careful with the decisions they make to avoid losing their heads, while our job market is less predatory so there are lots of opportunities here and the competition is not that fierce so losing our jobs for a gut made decision is not something that keeps us up at night. Having this freedom is and advantage in many cases where someone has to take a bullet to prevent a greater damage.

So if you'r planning your big start-up and you are short on resources, why not look south and give a try to a Mexican Development team which you can , we are just as capable, but closer and also we can arrange your visits to happen during big festivities (like "San Marcos Fair" on Aguascalientes, A.K.A. "The World's Biggest Cantina" ) so you can get as drunk as a mule, after all, what happens in Mexico stays in Spanish.


Friday, March 16, 2012

Java - Getting the memory size of an object.

Because the way Java language and the way JVMs are implemented, this apparently trivial task is more complex than it may seem specially when compared to C++ where all objects have a size() method. Java memory architecture is built to abstract the developer from direct manipulation of memory so that the developer can focus on more relevant tasks, this comes with a price.

There are 3 basic approaches you can take in order to do this all with their pros and cons:
  • Memory guess (Heap Size prior object creation - Heap Size after object creation = Object Size)
  • Java Instrumenting Query
  • Serialization

Memory Guess
This is the simplest approach because of the fact that you have a pretty easy access to the Heap Size via:

The issue with this approach is that you cannot control what is being thrown into the heap at a given time, JVM is shared by a lot of processes that run in a given machine so this is a error prone approach that is not recommended.

Java Instrumenting Query

Starting on Java 5, all JVM have built in instrumentation features . This features can be used to monitor objects size in memory by creating an agent and setting it up for the JVM. This is by far the most precise method of getting the object's size from memory, but it's by no means the easiest/straight-forward. Another drawback is that this may change depending on the JVM you are using (the next example applies only to Oracle's Standard JVM 5 )

The agent looks something like this:

import java.lang.instrument.*;
import com.somepackage.SomeClass;

public class MyAgent {
  public static void premain(String args, Instrumentation inst) {
    SomeClass obj = new SomeClass();
    long size = inst.getObjectSize(obj);
    System.out.println("Bytes used by object: " + size);
Then you need to register the agent to the JVM by initializing the application with the folowing parameters:

java -javaagent:agent.jar

That will cause the agent to be registered on the JVM instrumenting layer where it will be able to monitor object's size.
Next you can access these feature with something like:
public class MyAgent {
  private static volatile Instrumentation globalInstr;
  public static void premain(String args, Instrumentation inst) {
    globalInstr = inst;
  public static long getObjectSize(Object obj) {
    if (globalInstr == null)
      throw new IllegalStateException("Agent not initted");
    return globalInstr.getObjectSize(obj);
As you have certainly noticed this is no as intuitive as it may seem.
This technique uses Java's serialization features to calculate the objects size. This is not the most precise way to do it because memory specific serialization works in a slightly different way than regular object serialization but its a pretty good approximation. One drawback of this approach is that it requires the object to be measured to be Serializable.
This is how a method that mesures the size would look like:
public long sizeOf(Serializable object){
 if (object == null) {
  return 0;

  final ByteCountingOutputStream out = new ByteCountingOutputStream();
  new ObjectOutputStream(out).writeObject(object);
  return out.size();
 }catch (IOException e){
  if (log.isWarnEnabled()){
   log.warn("Unable to determine object size: " + object.toString(), e);
  return -1;
One of the greatest drawbacks of this simple approach is that OutputSreams in general are one of the most commonly known resource hogs in Java so you should treat them with care.

Sunday, March 11, 2012

Crítica a "10 Ideas Erróneas sobre PHP"

Hace algún tiempo me encontré con un post que hablaba sobre las 10 ideas erroneas sobre PHP. Me pareció interesante la idea de hacer un arquetípico post de 10 puntos defendiendo un lenguaje de programación, situacion que por si misma me parece un tanto chusca.

Antes de empezar quisiera aclarar algo. He sido desarrollador de PHP por más de 6 años (de hecho siempre me he considerado un PHPer en recuperación). Dada esa experiencia puedo decir sin temor a equivocarme que PHP es una excelente herramienta para el 95% de los proyectos Web (pequeños), es accesible y tiene una comunidad bastante extensa y heterogénea (esto puede ser un problema en ocasiones). También desarrollo en Java desde hace 7 años y he hecho algunos proyectos en C Sharp con .NET, Flex y actualmente me encuentro en un desarrollo que utiliza Grails (Groovy on Rails) y Griffon por lo que he tenido algo de experiencia con tecnologías muy distintas y filosofías casi opuestas.

Puedo decir con mucha seguridad que PHP definitivamente no es suficiente para proyectos Enterprise donde se tienen que considerar cosas como Estándares, Instrumenting, Automatic, Procurring, Mensajeria y casi cualquier cosa que tenga que ver con trabajar en ambientes distribuidos (en cluster). Los short comings de PHP se deben precisamente a la falta de una plataforma de desarrollo dirigida no solo por la comunidad sino regulada por alguna instancia que la mantenga vigente y sobre todo actualizada.

He aquí mi crítica a los puntos tratados en el post mencionado:

1.- PHP no es un lenguaje “compilado”, es un lenguaje interprete:

El hecho de que el motor de Zend permita "compilar" los scripts a un estado intermedio optimizado (bytecode?) no quiere decir que el lenguaje sea compilado ya que esto es una funcionalidad del motor de Zend y no del lenguaje (La inmensa mayoría de los proyectos corren en una instalación estándar de Apache). Lo mismo se puede hacer con Javascript utilizando Rhino (y algo de voodoo) y eso no hace a Javascript un lenguaje nativamente compilado, o si?

2.-PHP no puede… (Acceder a Memoria, Utilizar Hardware, etc.)

El tener que recurrir a un lenguaje de bajo nivel para compensar las carencias del intérprete de PHP valida precisamente esta afirmación. Es lo mismo si yo digo que con Python puedes leer los pensamientos de las personas... claro solo necesitas crear el Hardware que lo transfiera a paquetes compatibles con TCP/IP y lo envíe hasta el servidor donde Python los leerá.

3.- PHP no puede hacer algo que se puede hacer en la lengua X.

Este punto es redundante con el punto 2, creo que el propósito de incluirlo fue meramente de marketing para llegar al mítico "10" en la lista para que se vea más “oficial”. Sin embargo al inicio listé una serie de cosas que PHP no puede hacer y durante el transcurso de las demás criticas incluiré más, y no solo por la limitante de ser un lenguaje Script interpretado y estructurado, sino que a Diferencia de Java o C (Utilizando .NET) PHP es solo un lenguaje mientras que C y Java son Plataformas de Desarrollo. Ahora, casi cualquier cosa es posible con la cantidad de tiempo y recursos necesarios el problema es el esfuerzo requerido para hacerlo, en cuyo caso PHP requeriría un esfuerzo ENORME para lograr hacer algunas cosas que Nativamente los Frameworks de Java y .NET.

4.- PHP es solo para el desarrollo en WEB.

PPH fue concebido con el propósito de hacer paginas dinámicas y es claramente un lenguaje para desarrollos web. Es decir, no puedes programar drivers para una tarjeta gráfica o un Smartphone con PHP, los usos que planteas son solo extensiones del propósito WEB del lenguaje.

5.- PHP solo es controlado por Zend.

En esto tienes toda la razón. Lo que me parece curioso es que puedo inferir basado en tu comentario que por alguna razón consideras que el hecho de que PHP sea controlado por Zend es algo de alguna manera negativo. Me parece curiosos porque eso es precisamente lo que le ha faltado al lenguaje durante más de la mitad de su existencia; Una instancia seria que lo regule, esto permite que la evolución del lenguaje y de toda la gama de tecnologías que las que depende sean dirigidas y sean por lo tanto más exitosas, propongan más avances y por lo tanto atraigan a más desarrolladores. Eso ha sido uno de los grandes éxitos de Java (Con SUN y ahora Oracle) y de C y C++ con .NET (con MS).

6.-La documentación de PHP es incompleta he insuficiente.

Existe documentación oficial del lenguaje y es bastante completa. Sin embargo al no haber regulaciones ni estándares cada Liberia puede o no tener documentación suficiente o de plano no tener documentación alguna, pero esto no es algo exclusivo de PHP ya que lo mismo sucede con Java por ejemplo, aunque en menor medida ya que los desarrolladores Java favorecen grandemente a aquellas librerías que se apegan a las implementaciones sugeridas por Oracle o SUN en su momento y eso es un incentivo fuerte para que aquellas que no lo hacen caigan eventualmente en desuso y desaparezcan. Esta es otra de las ventajas de tener una instancia reguladora.

7.- Los proyectos de PHP no son reutilizables, ya que no son orientados a objetos.

En esto tienes razón también, pero por las razones equivocadas. Wordpress es un CMS y el usarlo no significa reutilizar código. Lo que la crítica plantea es que existe un gran número de desarrolladores PHP que no tienen ni siquiera fundamentos básicos de OOP. El OOP implica (usándose bien) componentes reutilizables por lo que muchos desarrollos en PHP no cumplen con esta buena práctica. Sin embargo, nuevamente esto no es un problema de la tecnología en si sino de la comunidad que hace mal uso de ella.

8.-PHP es peor que Ruby On Rails, Python Django, X framework en otro lenguaje

No creo que se pueda comparar un lenguaje contra un framework. El acercamiento orientado a modelos de Ruby on Rails o Grails es muy útil y muy fácil de usar para cierto tipo de proyectos, pero calificarlo como "mejor" es completamente subjetivo. Ahora es una realidad que el crecimiento de estas tecnologías es algo que debería alertar a los desarrolladores PHP ya que ofrecen lo mismo que la plataforma PHP pero mucho más robusto y accesible. Creo que la transición de PHP a Ruby on Rails es algo que se puede dar de forma muy natural para un desarrollador PHP, muchos de los que conozco ya han comenzado a agregar Ruby a su CV. Ruby debe ser visto como una herramienta más en el arsenal del desarrollador y no como una competencia, estamos hablando de tecnologías de desarrollo no de religiones.

9.-PHP no es bueno para los sitios Web escalables o aplicaciones de alto rendimiento

Facebook es una excepción. La razón por la que esa hecha en PHP no es porque haya sido la mejor opción sino porque era lo que Mark Zuckerberg sabia usar cuando comenzó el desarrollo del sito y desde ahí se comenzó a ampliar el fundamento que el planteó. Facebook ha tenido que compensar las limitantes de PHP utilizando técnicas bastante interesantes de Infraestructura y por eso el sitio opera bastante bien, pero insisto, esto no prueba que PHP sea apto para aplicaciones de alto rendimiento ya que su éxito dependería de herramientas externas (y algo de voodoo). Este artículo por ejemplo habla de cómo tuvieron que reescribir desde cero el Intérprete de PHP para poder hacer su plataforma extensible:

10.- Los desarrolladores de PHP son baratos porque no están calificados

En esto tienes toda la razón en una parte, es mentira totalmente que la razon sea por falta de calificación. El costo de un desarrollador obedece a las reglas de mercado de cualquier servicio o producto; Oferta y Demanda. Existen menos ofertas para desarrolladores PHP y muchos desarrolladores y muchas ofertas para Java y .NET, y pocos desarrolladores. Es por eso que Java y .NET es más caro porque es un bien "escaso" y por lo tanto los desarrolladores Java y .NET ganan mejor que los PHP (de 25 a 30% más dependiendo del Seniority).
Lo interesante de esto es ¿Qué causa esta diferencia de números?. PHP al ser una tecnología mas accesible permite que más gente con menos experiencia pueda adoptar el lenguaje, Mientras que Java y .NET tienen una curva de aprendizaje mayor y son más demandantes como primer tecnología para la gran mayoría de la gente. Yo creo (aunque no lo podría probar) que el éxito de PHP se debe precisamente a esta accesibilidad (No ser fuertemente tipado, el OOP es opcional, No compilas, no hay un framework o API que debas aprender para poderlo usar, No te metes con Patrones de Diseño si no quieres, No hay Maven ni ANT ni builds, ni dependencias, etc) pero como todo tiene su costo y este es que siempre habrá más gente y más competencia y por lo tanto los sueldos no son tan buenos.

Para concluir:

No soy muy fan de este tipo de posts porque hacen parecer a las tecnologías diferentes como religiones y plantean una división en la gente que no es realista. Las tecnologías son solo herramientas y como tales hay unas que son buenas para clavar clavos y otras para apretar tornillos, esto no las hace ni mejores ni peores. Existen algunas herramientas que tiene más de un uso y otras que son más especializadas eso es todo. Lo importante como desarrollador es que no te aferres a al lenguaje que sabes usar como si fuera un credo infalible y te ofendas cuando alguien que maneja alguna otra tecnología señala fallas de la que tú sabes usar y trates de defenderlas ciegamente. Lo importante es que mantengas la mente abierta y que agregues más de esas tecnologías a tu caja de herramientas y te hagas un desarrollador más completo. Quieres ser un mejor desarrollador PHP? Simplemente aprende Java, Python, Scala, Lingo, C o cualquier otro lenguaje.

Thursday, March 8, 2012

Another nail in the Flash's coffin - The rise of HTML5 Games

You'd probably already heard about Game Closure, but if you haven't this is what you been missing...

Game Closure is an independent student start-up company that developed a pretty interesting and amazingly robust Javascript/HTML5 game SDK. The SDK can be used to create games not only for web browsers (Facebook games) but they can be deployed also to iOS and Android devices. The SDK offers client/server real-time communication so this opens the possibility of massive multiplayer capabilities.

They have been recently in the spotlight turmoil since they presented Pop Star Defense, the first game to run in all mentioned platforms which they presented on Google I/O last summer. The interesting thing here is that this endeavor usually required up to 6 months to accomplish by traditional means to any Game Developer company regardless of their size, but it only took 5 weeks to the guys on Game Closure so everyone is looking at them with dollar signs on their eyes since then. Probably the most notable of this eagerly interested companies are of course the FaceBook and Zynga couple but also includes Motorola and EA.

I'm almost certain that Zynga will be the one ultimately acquiring the company, that's mainly because they lack the any solid HTML5 strategy this becomes obvious when you look at Zynga's game portfolio and realize that its almost 100% Flash based. In a culture where Flash is decaying and lingering like a sick old cat Zynga needs to make a tremendous leap before someone else picks up the market they drop to the floor , so for Zynga, Game Closure is precisely the way to get that leap. It has recently announced that Zynga has pushed the offer to around $100 million green bills, this is almost 8 folds bigger than the last offer Game Closure received (which was around $12 million).

So I guess will be seeing HTML based farms, coffee shops and cities in our friends and wives Facebook. This is just another push towards the edge of the abyss of oblivion for Flash. As I have expressed on on the past, the only thing (IMHO) keeping Flash from flatlining is precisely the dependence Zynga has (had) on it…

Wednesday, February 29, 2012

Beyond Technicalities - The Importance of Soft-skills in Candidate Selection

When interviewing a new candidate to work in our team its easy to focus on the technical experience and knowledge s/he has. This is completely valid considering the candidate is intended to cover a position in the team that demands her/him to be as tech savvy as possible. However this in fact causes that we sometimes overlook on a set of skills that can prove far more vital to the general health of the project and to the development of the person we are interviewing than specific technical skills. I'm of course referring to soft-skills and general emotional intelligence. I can't overemphasis how critical it's for us to recognize skills that lay beyond technical knowledge during an interview. The ability to recognize those from those required technically means the difference between hiring someone who will be willing to learn and adapt to how we do things while eventually adding value to the team and hiring an otherwise apparently qualified individual with that turns into an intoxicated rabid weasel with keyboard abilities every time someone dares to speak to him/her.

Its important that we remember that developing software is primarily a trade that has to do with people interaction and deep communication not with good code. The trick here is that recognizing soft-skills and evaluating them is much more difficult due to its subjective nature (and the fact that people don't come with user guides).

We must be prepared to identify when a person fits the profile we are looking for with his/her technical profile and with his/her soft-skill profile. This are some of the considerations that you might want to take on your next interview:



Communication skills are one of the most useful skills anyone who is on the consulting business as we are must have. In my experience, nothing has the level of destructiveness that could render an otherwise good project into a flaming Hindenburg like bad communication.One of the most insightful types of interviews is the one where the candidate communicates so well that you let him establish the pace and the direction of it. However communication comes in different flavors so if you find yourself in an interview where you basically need to pressure to get monosyllabic answers doesn't necessarily means that you are in the face of a poor communicator (although its very likely), it could be just that s/he is nervous or that her/his communication skills are more developed on asynchronous communication (which is extremely common to find among people on our trade) so s/he may be stuttering when speaking but could be able to write down his/her ideas like a poet, so try not to rush into conclusions, you need to learn you to distinguish between the to cases. A good way to clarify this point is to read his/her resume, specifically the part where most people describe themselves or their expectations, read between the lines, you have no idea how reveling a well read resumes are, they are just as reveling as family drawings from a kid.

A good exercise you can do during interviews are open questions that require the candidate to narrate a story. Like:

"What do you think was the most challenging event you have faced and how you dealt with it?"

This is a standard interview question that may look like you are interested in how good problem solver s/he is but instead pay attention to how well s/he can carry you through the events and how well s/he is able to make you empathize with the situation. Now, you evaluate how good they listen and comprehend you can use simulated scenarios. My favorite is the "elevator on the 100 stories building" design. It goes something like this:

"Consider you have a 100 stories building and you are required to design the software that will operate the elevator, how would you begin to design it?"

This exercise is extremely useful to evaluate OOP concepts and working methodologies but its also a great way to evaluate communication skills because people need to follow specific requirements and react to changing conditions. At some point you may interrupt and state that the building managers decide to add an extra elevator or that the power consumption is now a CTQ instead of the speed and so on and so forth.
So try to pay attention to how people answer and not just what they answered.

Interpersonal Skills:


This set of skills are probably the most overlooked of them all. Interpersonal skills have to do with how well someone is able to establish empathy bonds with other people.This is extremely important when working in team organized jobs like ours. People interaction depends on empathic bonds in a very basic level, this doesn't mean that in order to have decently performing teams all team members need to be BFF's(even though that this in fact increases team performance dramatically) but they certainly need to be able to spend 8hrs a day, 5 days a week (sometime even weekends) together without poking out their eyes.
Teams need to operate with a sense of harmony between their team members, beyond personal agendas and amalgamating a bunch of different personalities. In my opinion there is probably nothing more poisonous to team performance than a douchebag regardless of his/her technical skills, so treat this point with the care it needs. Try to perceive how likable people are during an interview after all you will spend more time with him/her than with your family or friends.

A good way to do that is to ask people related questions like:

"Who was your best boss so far?"
"How is you relationship with your current team?"
"What's the best and the worst to your opinion of working in teams?"
"How do you think your current team members would describe you?"

Interpersonal issues are almost always correlated to communication issues, people who are unable to interact with others don't communicate well either so expect to find them always in pairs. Also try to establish a friendly environment during the interview so that you help people open and connect which in term leads to a very fluid communication.

Multidimensional Abilities

We are very complex creatures that need balance on all we do to stay emotionally healthy.A very common way to maintain our emotional health is to grow interests that differ from what we do for a living.Try to inquire people about what their personal interest beyond their jobs are. This is a very good way to evaluate emotional health but also consider that multidisciplinary people add a lot of value to a team because they have a more varied set of perspectives and a acute insight in areas that might no one else know. A word of caution; this is probably the area where people tend to lie the most so it's important that you keep in mind that and try to go ad deep as you can.I have found that direct questions like "What you like to do on you spare time?" may lead to answers like "I love reading ,playing football and writing essays in scientific journals", but when you ask what was the last book they read you get no direct answer at all (you may call this the Peña-Nieto syndrome if you like).

I prefer a more indirect approach. What I do is ask them directly and dig into specifics, like for instance if someone tells you they like music you ask what kind and what is their favorite performer/band. Also I like to throw a hypothetical scenario that is great for mining this kind of information; it goes like this:

"Imagine that tomorrow you find out in the news that Bill Gates just passed away and he decided to inherit all his fortune to a random person in the world that turned out to be you. So you now have your financial future ensured for the rest of your life and probably for a couple of generations. Considering that you no longer need to work to live, what do you think you'll be doing for the rest of your life?"

You cant imagine how many times people have told me that they will drop everything relevant in their lives and spend the rest of their life in a yate, drunk and in endless orgies… but every now and then I get the very valuable and honest answers where people lets me know about their true passions in life like backpacking through the world, or founding their own software company or their own children baseball league. Is that doesn't tell you anything about someone, I cant think of anything that does...

Try not to dismiss the relevant information you get out from this questions, it may seem mundane and unnecessary to inquire about tastes in music, films, books and sports, but in fact that information tells you a lot of the interviewee personality which may be relevant to the interpersonal skills and multidisciplinary abilities; someone who likes to write is most likely an adobe average writing communicator, someone who's dream is traveling around the world is probably a curious person who is not afraid of changes, someone who perceives financial dependency as the only thing keeping them away of living a hedonist and senseless life may not be a very committed individual.

Remember that you build your teams, everyone is ultimately responsible, the overall environment you perceive in your team is never product of chance but it's the product of years of conscious selection, training and nurturing, everyone is accountable for keeping it the way it is. So next time you find your self on a interview bare that in mind and favor the inexperienced witty likable guy over the douchebag developer demigod.

Wednesday, January 18, 2012

The restless RESTful-ness

One of the things that I love of the software development trait is how fast things change. We are in a never stopping stream of new ideas, changing paradigms; the essence of pure innovation.
However, once in a while we look back to old dusty corners of what we used to do and believe and find out that those old forgotten ideas taken from mistaken were actually right all the time. Such is the case for REST architecture, a pretty old idea that fell into oblivion just to become the new trendy buzzword a couple of decades later.

Just for historical context; REST architecture was created along with the HTTP specification almost 20 years ago. The idea behind REST is to provide access to resources via an URI, each URI returns the resource representation on a different state, part of the data retrieved from each step contains the means (links) to access a different resource's state (sounds pretty familiar when explained in that way, doesn't it). If you haven’t heard of REST until recently that’s probably because the term was not coined until 2000 by Roy Fielding who was part of the team that came up with the HTTP 1.0 and 1.1 specification, cofounder of the Apache HTTP project and board member of Apache Foundation.

REST services have recently been brought back into the trendy stage. I personally believe that this sudden revived attention has happened due to two facts:

  • The ubiquitous presence of JSON in web applications grants to developers a simple data format that is not only JavaScript native but that is also tied to the HTTP protocol which is the vital breath of the web. With that in the picture and the recent (like 10 years recent) hype in SOA applications this seems like a solid option.
  • People are just sick of trying to implement over-complex and verbose SOAP based services ("Simple Object Access Protocol" is more like a sarcastic name for it )  for simple CRUD non-document based applications where tight security is not a CTQ nor is distributed computing and most of them fall into that category.

However with the hype normally comes the confusion. I have seen a lot of applications that claim to be RESTful just because they user JSON  request/responses strings.  Allow me to explain why I don’t agree with that.

REST web services stand over two main principles or rules:

  • Decoupling through SOA
  • Hypertext driven interactions (HATEOAS)

Decoupling through SOA and Hypertext driven interactions

One of the key points of SOA applications in general is to reduce coupling. SOA is intended so that huge applications can be chopped into smaller specialized distributed entities or services that can work together as a whole so that they can be designed, developed, supported, maintained a hosted in a more sustainable and efficient way.
Each of these services can be built with the technology that better fits the specific needs of each one. This services need to provide some way for the clients to know what they can do and how to do it (decoupling).  As SOAP relies WSDL or WADL so REST relies entirely on the hypertext data returned on the responses to client requests. A RESTful service must provide the client with all the means of interaction (URLs or how to build them) in order to comply with de expected decoupling.  If your REST services require for the client to have certain insight of how your application works beyond a basic knowledge of the exposed resources and the initial URI, or if the services are not using the HTTP native methods to interact with the resources exposed then that is some weird RPC with JSON, not RESTful services (I’m not implying that RPC is bad or inferior, but its definitively not REST).

Another critical difference between REST and RPC/SOAP; REST leverages on the already existent CRUD HTTP methods (PUT, POST, GET, DELETE, INFO, TRACE, OPTIONS, HEAD and CONNECT) while RPC/SOAP services define their own interactions (verbs).  RESTful web services also base the entire interaction in the hypertext received as part of the response (hypertext being XML, JSON , YAML or whatever data representation supported by HTTP ), in contrast SOAP is in fact an XML based protocol so it is not tied to HTTP as REST is (This last claim is debatable, though).

SOAP is still the W3C standard king by all means for all related to web services, it’s a robust protocol  (with a ton of features like WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets… not simple, definitively not simple at all… unless you compare it to CORBA) ideal for B2B interactions and distributed environments. 

For more simple services REST is a simple yet solid option worth trying but must of all worth doing it the correct way.