Archive

Archive for the ‘rants’ Category

reflexiones sobre el rol de arquitecto…

March 14th, 2016 No comments

Entre las “recriminaciones” que son cliché habitual acerca de los arquitectos y su rol, además del síndrome de la torre de marfil, es habitual oír quejas acerca de esa tendencia entre a querer abandonar los proyectos una vez que la parte digamos “interesante” de los mismos está finalizada o a punto de finalizar (¿instinto de supervivencia? 😉 ). Es decir, que una vez que se ha planificado la arquitectura, se han agotado todos las excusas para asistir a infinitas reuniones y desayunos de trabajo, los viajes y se han planificado las ejecuciones y todo parece perfecto sobre el papel, lo famosos arquitectos desaparecen.  En realidad, no sé si realmente existen estas figuras mitológicas tal cual hoy día, tal vez antaño, pero yo no las he visto, aunque si he visto gente con los pies muy lejos de la tierra en todo tipo de posiciones.  No creo que sea solo culpa del ser humano individual (si bien es muy cierto eso de que “everyone wants to design, nobody wants to maintain”…), sino también de las organizaciones, que al fin y al cabo son construcciones colectivas.

 

Hay otra forma de ver las cosas: el arquitecto debería ser el propietario “end-to-end” de la solución.  Es más, este rol ni siquiera es algo fijo sino que debería cambiar o evolucionar en consonancia con las distintas fases del ciclo de vida del proyecto.  Creo que esto no se reivindica o se resalta suficientemente, tanto para unos como para otros. Teóricamente, nadie mejor que el arquitecto debería conocer la solución mejor.  A nada que uno haya estado en esta industria suficiente tiempo, se dará cuenta que poco o nada tienen que ver el papel y esos archivos .vsx iniciales con la implementación real del sistema al final de la “larga marcha”, y lo que parece muy completo y casi “perfecto” en los powerpoints – que lo soportan todo -, no tiene nada que ver con la realidad ( que básicamente es lo mismo que les suele pasar a esos ejercicios de wishful thinking que son los Gantt, especialmente en el caso flagrante de aquellos creados antes de tener claros los requisitos, ni de haber tirado una línea de código, los Gantt “promesa política” que los llamo yo, pero ese es tema para otro post ).  Al igual que ocurre con los dichosos Gantt que tanto daño han causado, es fútil pretender que se puedan conocer de antemano todas las circunstancias cambiantes, errores, problemas, asunciones y premisas que cambian y todo tipo de factores imposibles de anticipar, porque al final se trata de sistemas “vivos” (creo que los matices en “live” lo expresan mejor).

 

Debido a todo esto, es imprescindible que el arquitecto continúe en el proyecto – al menos en un rol de supervisión y liderazgo técnico dando soporte al equipo y a negocio -, hasta incluso durante la fase de entrega, donde sigue teniendo un rol importante.  No basta con ser un arquitecto en su torre de marfil, y se debe revalidar el papel del “coding architect” que conoce también la implementación de su solución y los requisitos de infraestructura, y como dar soporte a los requisitos no funcionales elicitados.  Ciertamente, hoy día se ha desgranado o especializado tanto el papel del arquitecto que el termino corre grave peligro de no significar nada, o de significar cualquier cosa, y dependiendo de la empresa tenemos simultáneamente cualquier combinación de data architect, business architect, integration architect, Infrastructure architect, solutions architect, Enterprise architect, information architect, delivery architect, UX architect, etc. etc.)

Data science


Al hilo de esto lo cierto es que tal vez el rol del arquitecto sea tan difícil de definir porque las habilidades y tareas del rol van cambiando según el proyecto va agotando fases en su imparable carrera hacia el <sarcasmo>más fulgurante éxito, directo al cuadrante mágico</sarcasmo>. Por lo que me toca más cercano, es fácil ver como el solutions architect debe irse convirtiendo en un delivery architect (podríamos decir arquitectos de entrega o algo así, pero queda fatal). Esto al final, no es más que insistir en el principio de responsabilidad (responsibility and accountability) y de propiedad (ownership –  a veces los vocablos ingleses parecen transmitir mejor la carga semántica).  Al principio será más el responsable de entender bien los requisitos, coordinarse con los stakeholders de negocio (son diferentes skills, como vemos, tanto técnicos como sociales) y entender los limites tecnicos, presupuestarios, manejar expectativas, el entorno político y cultural, y dar lo que parezca la mejor opción, a su juicio y con los datos disponibles.  Sin embargo, nada – y nunca mejor dicho lo de “nada” – acaba con la entrega de un montón de documentos, de entregables definidos por nuestro framework de arquitectura preferido.

 

El aspecto clave durante la vida del proyecto es la gestión técnica, alejándose de esos arquitectos extremófilos acostumbrados al aire enrarecido de la sala de juntas, donde de nuevo tenemos capacidades muy diversas que aportar: gestión de stakeholders y/o grupos de interés, gestión de deuda y riesgos técnicos, calidad, metodologías, gestión de equipos, “fit-for-purpose”, gobernanza y, sobre todo, asegurarse de que la solución no se desvía del alineamiento con la arquitectura empresarial y los objetivos tácticos o estratégicos a los que debe su existencia.

 

Aquí es donde probablemente la línea entre Solutions Architect y Delivery Manager se solapa mucho, y podemos hablar de otro rol más, el de Delivery Architect, y es que el delivery manager raramente tendrá el mismo conocimiento que el arquitecto de una solución específica, ya que éste es el propietario de la solución completa, por tanto es de suponer que el arquitecto sería el que tiene la mejor y más completa visión y el conocimiento sin el cual, el Delivery Manager tendría muy difícil ser capaz de cumplir con sus responsabilidades correctamente.  A menudo el factor decisivo en el éxito o no de un proyecto será la colaboración eficiente entre el Delivery Manager y el arquitecto, no la calidad sobre el papel, no la belleza del diseño de la solución en unos cuantos visio o UMLs. El arquitecto debe por tanto ayudar en todo al Delivery Manager para que se tomen las mejores decisiones. En esto el arquitecto pasa a ser un delivery architect. Su rol va – y debe hacerlo – mutando según evoluciona el proyecto. Esta figura que llamamos el delivery architect también debe de no perder de vista el foco en los requisitos no funcionales. No solo se trata de definirlos – que también – sino de asegurarse que el Sistema o la solución propuestas y desarrolladas se adhieren a dichos requisitos. No olvidemos que al final se trata de que la arquitectura de soluciones realizada sea operable y efectiva desde el punto de vista del coste y de las estrategias definidas a nivel empresarial.

A riesgo de sonar muy pomposo, cierro con una cita de un libro que no he leído

Se audaz y astuto en tus planes, firme y perseverante en su ejecución, decidido en encontrar su glorioso final.

Carl von Clausewitz, De la guerra 

 

 

Speed of understanding

December 4th, 2015 No comments

Is your code easy to understand, can someone new to the codebase grasp quickly most of the intent of the code? What is the speed of understanding of your code.While this is basically the old idea that code should be readable by humans – that includes business people and managers 😉 -, what strategies and tactics can you put in place to gain speed of understanding as an intrinsic quality in your codebase?The thing is that very rarely someone who actually wrote the code is the one that will also maintain for the entire lifetime of the software (and, well, even in that case, knowledge about a codebase is one of the most ephemeral things in life, especially in the case of significant – read, large – codebases).

When a codebase is not so well organized, it very quickly becomes so confusing that even the original team members find themselves scrambling and frantically searching through the codebase in order to find that snippet they wanted to reuse, that pesky function the name of which they can’t recall ( for some reason, some pieces of code or some function names are much harder to commit to memory and find quickly. Treat that as a warning that some action is needed there!).I assume that we are naturally working in a OOP environment, which probably lends itself best, although of course functional languages and strange beasts like javascript can do the trick as well.Two of the strategies (or tactics maybe) that help the most are:

 

  • Use of DDD, a well codified plain-object domain that models / reflects your business, which is how DDD goes about creating a shared vocabulary between business and engineering. That will lead you to having a DSL for the business domain.
  • Write the client code first – the client code that you would like to have to write. This scenario is greatly enabled by having some DSL first, and, of course, hindered by not having that DSL in place. This is similar to using TDD in what some call “outside in” TDD.

 

These are for me strategies, more that mere tactics. Both are supported of course by TDD, as you can actually use TDD as a “discovery” too for that client code you want to be writing. However, I am willing to bet that if you have non-trivial business knowledge about your domain already, you can skip that process of discovery and write the code you want to see (as in “be the change you want to see”, you know ), without that meaning “do not back up your code with tests.”  That being said,  it is easier said than done of course.

 

governance frameworks

 

Now, there are tactics as well. Nothing trailblazing here:

 

  • Excellent naming conventions and the discipline to uphold them. It’s already a distant past when one had to save precious bytes by being skimpy on names. Not anymore. Probably only in the case of lambdas, pattern matching, etc. should you be getting away with names like, x, _, temp, and so on.
  • Good commenting habits (there is a lot on this in that great book – Code Complete)
  • Refactoring to small single-purpose functions.
  • Do not overdo the “look ma how smart I am”. Sometimes, they say write code that is not “so smart” (clever one-liners just because I can, nested ternary operators, complicated lambdas), and while that is true to the extent that you don’t want to write production code like this or this, that does not mean you do not take advantage of (relatively) “advanced” features in your language, for fear that other developers coming in later are not familiar with those. They might never learn those!
  • Consistent style in all things: naming, spaces, indenting.
  • Share the code. Have other developers from other teams have a look. Even ask a lay person, your boss for example, to guess what a piece of code does.

 

You need to use the strategies underpinned by the tactics to achieve that speed of understanding.Would there be a way to actually measure that quality of speed of understanding? I am not that smart to figure that out. Probably not in an absolute way, as there are different styles and preferences for programming – some like fluent api style, others call it the train wreck, for example.For the time being maybe, it’s enough that you always keep that purpose in the back of your mind when coding, until it becomes a habit.
Let me have this as one purpose of mindfulness in coding from now on. Let’s be more aware of this when designing and coding.

Categories: coding, rants Tags: , ,

we don’t really have a strategy

June 12th, 2015 No comments

It is said a strategy has to have these components:

    • Purpose
    • Plan
    • Doable series of actions
    • Measurable goal(s)
    • A narrative

To this, I’d add that it is important as well to weight side effects as well as the validity of those goals. It could well be that a strategy could be beneficial in the short term, and disastrous in the long term, or cause a lot more damage to third parties (therefore, it is externalized and seems much less important) than the benefit it may bring.

Let me call them “risks” in a generic way. So a strategy must be iterative and open to revision at all times, if unforeseen results appear from those goals. Don’t fall for the trap of naive rationalization or the belief – wildly spread in politics today – of omniscience and infallibility.  Most often, I think we do not know how to do strategy.  And that probably we even can’t. It’s an illusion.

In both the business and the politics worlds, two elements are magnified and the important – and hard – stuff, neglected. We love simplified narratives with clear – albeit fallacious – causal relations, and we love the apparent purpose we made up in our heads – that is, we are focusing on the fairy-tale results, the dreamy end, the wishy-washy grand statements, and we want to obviate the hard part, which is designing your plan, deciding what work and efforts are needed, also to realistically assess if it’s doable at all in your context and then decide how you will measure success (or the lack thereof, in order to learn).

Assessment and measurement are to be done with metrics and numbers. These are notoriously and largely absent from political manifest and party programs for example – and nobody seems to be shocked by that glaring omission -, which are the perfect showcase of how the public at large prefers to focus on the narrative, the seduction part, and forget about the hard part (as bold as unsubstantiated slogans or mission statements as “reclaim the city for the citizens”, “build a fairer more egalitarian society”, for example), and that is probably because politics is not only the art of the possible, but is as well about deceiving and seducing in order to nudge oneself and one own’s clique into a rent-seeking position of power.

But the business world is also full of grand purposes, transformation projects and strategies (a lot of them digital, these days) that remain just that, dreams and a lot of meetings.  A strategy should inspire, yes, but before that, you need to perspire and work hard to come up with one.  One that is backed by cold hard facts, by sensible reasoning and assessment, by taking into account what worked and failed in the past as well.  It does not have to be something very complicated. Something like this is probably enough to get started.

STRATEGY
NARRATIVE Developing business CRUD applications for our clients can be very fun!
PURPOSE Position our company as a top software development boutique
PLAN Rather than rely on price-based race to the bottom competition, compete on quality and real value
ACTIONS Invest in quality training in bleeding-edge technology
Partner with great companies
and/or open source projects
position ourselves in the radar by writing blogs
speaking at conferences
publishing books or papers
MEASURABLE GOALS Are we getting more contracts?
Are we working with companies perceived to be leaders? what are your desired partners?
Have we moved into or towards thought-leader territory? if yes, how can you prove it?
Have we been able to raise fees and improve profit in projects? How much?
Are we delivering better and faster? Percentages, please?
RISKS Hard work is more prone to quitting
Complacency and relax
Harder to maintain momentum

I just came up with this in the time it takes to actually write it, so please excuse the simplicity, but I guess you have seen plenty of documents full of the three first points, and not so many of the other three, especially the last two.

Without those, a strategy is worthless.

Categories: rants, strategy Tags: ,

on the mastery, or control, of emotions

March 17th, 2015 No comments

In “The 48 Laws of Power”, author Greene states that

one of power’s crucial foundations is the ability to master your emotions. An emotional response to a situation is the single greatest barrier to power. Emotions cloud reason, and if you cannot see the situation clearly, you cannot prepare for and respond to it with control

If indeed an emotional response is one that clouds reason and hinders a rational assessment and response to a situation, and thus results in a reduced scope or a total loss of power, then it follows that the “infantilization” of the public and the overemphasizing of all aspects emotional and sentimental in the individual, that we have seen as a clear, established, and rising, trend in recent politics, is evidently looking to undermine, weaken and ultimately eradicate all manner of power in the individual sphere, the power of the individual to determine his own answer to a situation, his own rational reaction, searching to make him respond, act and conduct himself more like a child, in a sphere where only emotions that have been directed, manufactured and packaged by those holding positions of power, hold sway over the individual. Never have we heard so much talk about developing critical reasoning abilities in the individual while doing the exact opposite from state-controlled “public education.”

tie the knot / 刺钢丝

The deliberate debilitation of responsibility and stupidification of public life, as well as the widely held belief that if you were inspired by good intentions and lofty goals – no matter how empty-headed and misguided – then you did not, could not act wrong and you are thus excused of any harmful consequences of your actions, are manifestations of this trend, of this (not so) subtle and debilitating maneuvering.  Furthermore, one does not even need to measure the effect of one’s actions and decisions that were inspired this way.

In the age of narcissistic solipsism, the vindication of sentiment, the spurts of bland sentimentalism, empty good-willing grand statements, do-goody blatitudes and inane bleatings that we’ve had, and continue to, endure from our politicians and the media all look to extol the validity of sentimental response as supreme, to establish it as a superior and better thing that being a colder and more rational.  In this way, the individual loses and relinquishes, without even realizing it – which is the best way to co-opt somebody’s resistance-less cooperation – the capacity to react, to assert his own response.  Without as much as missing it, or even realizing he had it in the first place. This means a neat power transfer from the individual to the upper instances who actually hold power, and seek to accrue it.

Categories: rants Tags: , ,

Gaman

February 25th, 2015 No comments

‘To be honest, I had never come across this Japanese word Gaman until a few days ago. Like many words that come from Eastern cultures, it can be hard to find an accurate and complete translation, especially when these words are tied to, as is the case, philosophical or spiritual concepts that seem, initially, to have no equivalent in our Western cultures.

Gaman (我慢) can be roughly translated as patience, endurance, resilience, perseverance. That kind of thing that is not exactly fashionable in our world views. It can also be stretched to the point where it enters into ascetic territories, by also expressing “self-denial”. Incidentally, these same two ideograms, which come from Chinese, mean, respectively, I and slow: “me-slow”.

So, in this sense, Gaman is considered to be a desirable trait of a strong and governed personality, a virtue, an ethos or law with which to conduct oneself in all matter of life, and it relates to the more puritan or Calvinist idea of gratification delay.  Now, maybe these concepts of patience, endurance, resilience, perseverance, can, and should, come across as more familiar.

Asceticism and stoicism should, but aren’t, more well known in the West. At the end of the day, they belong in our philosophical traditions, those we seem to be reluctant to teach in our schools. But as everyone knows, these days you can sell an idea much better if there is an alluring and mysterious Japanese word supporting it, never mind you probably can find similar ideas in the Greeks and the Romans.

enfants riches, deprimés

 

I think that we have a serious deficit of Gaman in our current lifestyles. I know I have it; I am aware I should have more patience with things, starting with myself, but not stopping just there.  I believe most of us can agree we’re perhaps too prompt to cede to impatience, to be irked by the small inconveniences of modern life, of the workplace, of the society we’ve built, and we don’t stop to consider how comfortable that life is, for starters, in spite of its defects.

When we allow ourselves to be irritable, being that irritation triggered by what most often are actually just small nuisances, things that are part of life, even if we wish we could do away with them, we just prove we are immersed in a culture that has eroded and despised, mocked, that component of stoicism, of resilience, of perseverance to practically nothing. As individuals, we probably have very much neglected this core trait of a healthy character.This, in turn, is nothing new. Many others have already written about the problems with the drive towards ever more immediate gratification, our obsessions with attaining goals sooner than it might be realistic to expect. To grow at all costs, and do it quickly and exponentially; in all aspects of life; in all endeavors.

Who could quantify what that costs in terms of the anxiety that plagues so many in the Western world?

Think about it. The Chinese meaning is illustrative too, “me-slow”. I am sure you’ve heard about the slow movements, slow food, and such others. That’s a form of cultivation too. Of cultivating your character. Walk a bit more down this conceptual stroll, and you’ll see you’re already close to the revival of craftsmanship.

Perseverance, striving for mastery, cultivating that ethos, that virtue. It’s all related. The spontaneous emergence of these phenomena, away from public policies and such, shows there’s a certain want, a lacking, that is felt by a part of society, those who perhaps are more sensitive.

According to Gilles Lipovetsky, we’re living in a post-moralist society.  His rather interesting book Le Crepuscule du devoir (can’t say if it has been translated to English) precisely strikes home this point of the loss of morals. Now, don’t take this “morals” as the rather narrow sense of a certain type of religious, conservative, scared-by-sex-on-tv, simpleton morals, but in the sense of the individual losing – or that’s been made to lose – the criteria, the will and the strength to train oneself, to constantly improve, to strive for attaining worthy goals that will take time and toil, instead of looking only for the cheap and immediate steps that bring hollow gratifications as soon as possible, like rats in a lab maze.

No doubt this is a trait of our Western civilization, and probably our soft power is exporting it.  We need more Gaman.  We need to cultivate it in ourselves. In our kids, many of which are being brought up perhaps as brats that are way too spoiled. For them, this cultivation of Gaman is vitally important as they transition into teenage and early adulthood.  The way it looks now, the world seems poised to demand quite a big dose of Gaman in their lifetime, and I can only hope I going very wrong here, but that’d be a matter for a different rant.

Categories: life, rants Tags: ,

return of the conviction politician? WTF?

February 18th, 2015 No comments

I was reading this short article on the idea of the return of the “conviction politician” (whatever that might exactly be) and the, as of late, much adored, and hitherto unknown, Varoufakis. Frankly, this “conviction politician” idea does not seem to be that sound, if not downright scary. Were not Stalin, Mao or Hitler men of conviction too?

It’s a simple question, are we talking about a the management of a country or about vague, and mostly outdated, ideologies detached from reality, and in fact, impervious to it? Personal convictions usually rest on prejudices and ideologies that often are not amenable to any analysis of reality, and which tend to avoid realistic assessment of our environment when that assessment is going to yield results that do not fit in the range of acceptable results according to our set of beliefs.

It’s even funnier if you consider what would be the scenario if the “conviction politician” were to be one of traditional and/or religious convictions.  I can almost hear the cries, the outrage, the indignation from the usual flank of leftish commentators, who in fact, are ferociously conservative and fascist.

However, if the “conviction politician” is one that shares my convictions – he’s one of our tribe, of our church – then it’s a good thing.  It’s like freedom of expression, as long as it is my ideas that get voiced, all is well.

While a 100% technocratic with no “soul” approach is no good thing, having the wrong convictions and a twisted moral compass is no good either. Nothing proved that better that the worst moments of the XXth century, and the Soviets demonstrated what horrendous outcome results if you combine both things. If your approach is to appeal to solidarity after having binged on other people’s money, and having issued public debt like crazy on the backs of future generations (now, that’s some fucking solidarity as well), and the ask everyone to share the burden, what kind of proper and “right” conviction is that?

And that’s without even entering a discussion of one’s own idea of “right” vs. “what works” or “what has to be done” if you really want to do something for “the hungry in the streets of our cities”.  “The hungry in the streets of our cities” have been created by the reckless fiscal and budgetary indiscipline of the state and its very poor management of the economy, its siphoning off of resources from the real economy to its own expenditure, be it on feeding the beast, be it on its numerous and tangled client network, lobbies and vested interests as well as the social engineering experiments it loves to indulge in; by its meddling with job markets, by taxing companies into oblivion and discouraging individual initiative.

And of course by the absolute refusal to ever admit you were wrong, your policies were wrong or misfired. Never! It’s a sign of our times, this refusal to accept the consequences of our actions and decisions. We can see that across the entire gamut, from the single individual to the public sector and the state. It’s a habit that has permeated into the very fabric of what our societies are and the terms in which they think of themselves. Just like thingking that anything you do with the “right and good” intention has to be inherently right. It does not matter if those good intentions have unintended and wrecking consequences. It was done with good intentions in mind in the first place, so it is all justified.

There’s never any discussion of freeing up the economy, of loosening up the shackles the public sector has on the private sector, the sticks in the wheels.  Apparently solutions must be found within a very narrow set of options, because there are many taboos.  A very interested cadre of state lovers has succeeded in beatifying the state, pushing for the identification (confusion) between people and state, and often successfully. No matter how strong, your convictions and ideology aren’t feeding anybody, except maybe you. They become self-serving.  More worried with saving face against the promises and the “red lines” that were constrained in the first place by your own convictions. Since the discussion seems to be Kantian and philosophical, I’d recommend revisiting the concept of Schuld in Nietzsche. Maybe that can help point the moral compass in the “right” direction.

Categories: contemporary, rants Tags: , ,

understimating testing at our own peril

February 16th, 2015 No comments

Software testing is routinely underplayed, ignored and underestimated when planning a software project. Testing is not a single thing, rather it consists of different tasks, most of which take more time than many seem to think. Sadly, it’s quite common to give little thought to these tasks, as well as the risks associated with each. The temptation to cut corners on testing seems to be irresistible, even when paying that tax later on hurts like hell. So what is testing made up of?

First, somebody needs to come with an adequate selection of test cases. Here it is important to remember that the more code paths and components involved the better. Here it is important to make a distinction between greenfield projects, where test cases will likely be created by a stakeholder or a few of them with the most business knowledge, or in legacy projects ( sometimes called “brownfield” although sometimes they deserve to be called “scorched earth” projects 😉 ), where it is not rare at all that source code has to be analyzed, to find undesirable coupling points, main code paths, unwritten business rules, kludges, etc. This is rarely taken into account. However there’s always a dark area that the stakeholders creating the pure logic cannot contemplate, and that is all the intricacies of internal state. Any sufficiently complex piece of software that has been maintained and enhanced over the years by different people will have more than its fair share of things such as hidden fields, flags with obscure names and purposes controlling flow, rare branches for particular situations multiplying the code paths, etc. It’s relatively easy to automate the testing of a calculator, not so easy to for a complex business application with hundred of inputs, edge cases, business scenarios, different workflows, etc.

The thing does not stop at selecting the cases; you need to take care of creating some sort of system, document, artifact that specifies the tests and leaves room to store the results, to at least, document the state of the system at a given point in time with regards to the test case selection, how many of them were satisfactory and how many weren’t.

Somebody needs to take care of executing that test case selection. Do you have dedicated people for testing? do you have some degree of test automation? According to the risk elements introduced in point 1, this gets more complicated and time consuming accordingly. Test execution is the part that’s probably more amenable to automation, but also architectural decisions made here can make it much harder. Think of distributed architectures, microservices that act / react asynchronously, hard – potentially hard to automate end to end.

Test result analysis. If all goes well, then nice, if not, errors have to be analyzed, traced, the input that caused them captured in order to reproduce scenarios. And we can also question ourselves about the quality of our oracle here, if it’s available and how accurate and correct it is. If we are to deduce correctness of test results from the specification, it may become very similar to exegesis of ancient texts and scriptures, that is, tedious, time consuming, error prone, unclear, and the basis for endless discussion about the interpretation of requirements.

Debugging of error scenarios. Potentially very time consuming. Fault removal and regression testing. You do have unit tests at least, right? Test maintenance. Tests and documentation maintenance seem to be the lowest caste in the software world. It’s not that they are often slashed off to “gain” time, it’s that nobody wants to remember to do it. If not updated, their usefulness obviously vanishes quickly. Bringing up to date an obsolete test suite is another nasty effort.

umbrellas

get your umbrellas out for the impending shitstorm

In the case of big and hairy integration projects between different systems and components this is even more important. My experience is that in this sort of project the fallacy of perfect execution and the siren song of perfect planning contribute a lot to underestimating the time and effort to integrate components that have been developed separately and the testing of the subsequent assembled system. Additional factors such as geographically diverse teams and if different companies have been involved can only make it more complicated and time consuming.

Now, let’s travel mentally to that beautiful rare moment of calm at the very beginning of the project. This is not an cool and agile startup. We’re now in an old corporate behemoth. We do things differently here. So, we’re in this meeting and we’re guesstimating our deadlines, internal and otherwise and ballparking a release date that gets then set into stone. We all agree that 3 days for testing is enough. Yi-haaaaaa. And we said 3 days because after all, this is a project integrating SAP, with a BPM, with a web site, with a set of services, with whatever you want. (the use of 3 is just an example)

So we did it. We set up ourselves for a lot of pain when the time comes to assemble everything and test it. The old engineering mentality kicked in. We haven’t learned yet that software isn’t like that. Now you’re bound to a nerve-racking project end, the grand finale, as nobody thought the integration would be that hard, we had specifications and countless meetings after all, right? and that so much testing and refinement would be needed. The problem is that this was not the first or the second time we did that kind of project. So what is keeping us from learning not to underestimate the importance of testing, the value that it adds to the product we put out there? Why do we keep making this mistake repeatedly? The answers to those questions can probably be very varied, depending on organizations, but most often, it will be variations on these

 

    • We have to deliver faster and faster every day
    • but we don’t have the right means or practices (we don’t write tests or do tdd, we don’t have continuous delivery or only a poor man version)
    • this is a web project, and in the web you can have things done in 5 minutes
    • We have promised this deadline to our stakeholders / clients – and yes, we promised that date the first thing in the project, before we knew what we had to do, the complexity of the challenge and even before consulting our tech staff , and as we promised this date our asses are now on the line

 

Thus we persist in these base mistakes and we ignore testing at our own peril and keep suffering as a consequence.

Categories: rants Tags: ,