The usual rants

1. Senior Engineers

I had to work with a senior engineer (per our standards). He seems to have about 16 year of work experience on the same platform, .NET since its beginnings. Still it took him four days to make a simple NancyFX based RESTful API. And then about a week for running it in a container. Very hard to make him comprehend the documentation. Or understand conventions in software projects.

2. Architects

Yes, sometimes I feel ashamed that I am called an architect. It seems that wee are a peculiar breed that forgot that we do software. Some of my colleagues have their head so deep into their butts so that they cannot get out of their own paradigms. They consider that the single piece of software is the product on that they worked for years and it could solve all humanity problems by a matter of its configuration. They really have the philosophic stone. Too bad that their product doe not sell. Other consider them some ethereal creatures that do not have to do anything with code(that's peon work) and they stay in slideware land where they draw boxes. GO CODE DUDES! Draw nothing until you have tested at least partially your fucking suppositions. Don't stop on a single solution. Use the architectural methodologies that YOU say that YOU know (ATAM, CABAM, or other mambo-jambo).

3. Build managers

Well, Mordaks. Doing everything to hide their inability of understanding how software is constructed. They are never part of project but hinder projects by enforcing stupid policies and environments. They are irrational and cannot be convinced with arguments. They "know their drill" albeit nobody else does. Correct software is not created by pushing every night a compliant build environment. Correct software is with a good pipeline that means a good version control, fast compilers, TESTS and deploys. Many of them. Not only every 2nd year or so...

4. Myself

I really reached the conclusion that I speak in vain hence I have nothing to gain. So I should shut up and smile as Taylor Durden did when all the skyscrapers were collapsing. It makes no sense to make things right as long nobody cares. Everybody will continue getting its pay check. And nothing good or shippable comes out.
     

Scratch for engineers

I am often spending time at home playing in Scratch with my daughter. We can do so many wonderful things there. One of our favourites is to create a fairytale. We take princes, princesses, dragons and unicorns and make them interact. It is very nice to see dialogues, spells and fights based on the little visual language. It's truly addictive.

But what are in fact doing is programming an actor system. Actually Scratch is a very crude but effective actor system. It is not meant for doing production stuff as Akka but it can be used for showcasing some concepts and do quick, dirty and funny prototypes.

So instead of resorting to some heavy frameworks and dry prototypes why not make a funny prototype in Scratch? A scenario turned into in a fairytale? We could model some of the services as knights, some of the threats as dragons. Wouldn't it be funny to have a database princess? Or a unicorn dispatch service? 

The mental image of a fairytale might be more evocative on the long term and give some human touch to some abstract concepts. The prototypes get some story, they are no longer abstract proofs that a solution exists somewhere in the vast solution space.

Given that I am a dragon. When I receive "attack_dragon": Then I think "hmmm..." for 2 seconds. And I loose one head

One can read the above script in Gerkin terms.Does it make sense? Which one is more acceptable? Which one is easier to remember?

I am really thinking that Scratch can help learning in a funny way about actors, messages and programming.

And yeah, do some impressive presentations. Computer Science is full of these analogies, think about the "Dragon Book" or Valgrind. So, yes, I do not think that I am out of the line.

Scratch for Engineers

Created on 2018-06-19 08:58

Published on 2018-10-30 11:23

I am often spending time at home playing in Scratch with my daughter. We can do so many wonderful things there. One of our favourites is to create a fairytale. We take princes, princesses, dragons and unicorns and make them interact. It is very nice to see dialogues, spells and fights based on the little visual language. It's truly addictive.

But what are in fact doing is programming an actor system. Actually Scratch is a very crude but effective actor system. It is not meant for doing production stuff as Akka but it can be used for showcasing some concepts and do quick, dirty and funny prototypes.

So instead of resorting to some heavy frameworks and dry prototypes why not make a funny prototype in Scratch? A scenario turned into in a fairytale? We could model some of the services as knights, some of the threats as dragons. Wouldn't it be funny to have a database princess? Or a unicorn dispatch service? The mental image of a fairytale might be more evocative on the long term and give some human touch to some abstract concepts. The prototypes get some story, they are no longer abstract proofs that a solution exists somewhere in the vast solution space.

One can read the above script in Gerkin terms.

Given that I am a dragon. When I receive "attack_dragon": Then I think "hmmm..." for 2 seconds. And I loose one head

Does it make sense? Which one is more acceptable? Which one is easier to remember?

I am really thinking that Scratch can help learning in a funny way about actors, messages and programming. And yeah, do some impressive presentations. Computer Science is full of these analogies, think about the "Dragon Book" or Valgrind. So, yes, I do not think that I am out of the line.

Winds of change

Created on 2018-07-24 14:25

Published on 2018-07-25 14:52

In 1964 Thomas Gladwin compared the way that Trukese people and Europeans sail on sea. The Europeans tried to follow a plan and stay "on course" while the Trukese navigators were going hop-to-hop towards the objective and decide ad-hoc what will be the next segment and how to tackle it. While plans are clear ways of presenting one's goals and share information, in a deterministic, stepwise approach, the plans require that every possible outcome is already thought of and scripted in it. Plans are great when you know the space in which you sail, the distance to the next shore exact position of islands and ability to track progress (astronomically). Plans are great when you have maps.

What if you go into the unknown, in places where you just have a vision but no paths, no charted seas? Change is always exploratory and vision driven. In an enterprise, when change processes starts, there is no chart of the process. Probably there are some war stories that people know about about successful changes or failures but a given organization is in uncharted waters itself. Not all the stories are true, sometimes sailors exaggerate and not all the dragons are known. Basically plans are just retelling of the stories, motivational parables that give courage and determination to those who are handling the changes.

What I am trying to state is not that plans are bad, they are good in known areas. I rather want to stress out that change should not follow a strict plan but a set of actions that are geared towards a goal, in some situations not the original one. Columbus plan was to reach India going westwards and staying on course. Polynesian people discovered countless islands and probably some continents by sailing in smaller increments in a given direction. Columbus' plan failed (albeit it's failure was a greater win) but this shows that exploration and change cannot be safely done by following a script because of the unknowns. Plans are the perfect methods for improvement, when quantitative data is available as flows can be maximized by following the script. Exploration is about qualitative aspects dangerous/safe, easy/hard decisions. Polynesian people were sending ships to check the seas, some ships came back with new information so that the others learnt of it. This is the equivalent of prototyping, of "throwing nuts". Change should be first isolated to some parts of the organization so that failure should not generalize while success of the smaller changes can be generalized and retold as magnificent epics that would spark the imagination of the followers.

The agile principle of "respond to change" seems to me a more suitable way of handling exploratory issues. The vision shall be followed but steps, "situated actions" should be taken every time something new comes in the change process. The context is always different from step to step and shortcuts may be possible. In the animation above, if we consider the green as situated actions and the red as a plan we can see that the plan is easy to be derived when enough of the unknown is charted out. Although it looks that it is a waste of resources to explore things exhaustively, in real life there are lots of heuristics that can be used to limit the effort and keep focus on vision. (A* pathfinding animation taken from: http://www.andrewsouthpaw.com/2014/05/28/trailblazing-and-graph-searches/).

I'd rather sail the in organizational winds of change from hop to hop, following a goal and trying to find best paths from my current position than following a long plan, probably based on heard stories, on uncharted waters. Management should help by keeping the vision consistent and reminding it often, and offering rewards for those who follow the winds.

Surviving Vacation

I finally did it. After a full day of driving home through heavy rain I can say that my vacation is over. 

I feel relaxed. I can wake at 7 without any alarm. I haven't had any thought about work or politics for two weeks. 

So it means that I am ready for the next adventure, whatever it might be.

The interesting bits of the day

1. Oracle GraalVM: awesome - runs almost every possible language allowing for true polyglot development.
2. Kata Containers interesting alternative to Docker
3. Rhei Clock:Fascinating clock with a ferro fluid display
4. Bad sectors scanning tool: mechanical drives are still cheaper than SSD and provide higher capacity

Lean documentation tooling

Created on 2018-03-21 12:55

Published on 2018-03-23 07:33

In order to get a job well done the tools should be carefully chosen. However tools have to chosen based on the size of the job one's trying to get done. If the job is as massive as digging the Panama channel, a shovel won't help much and also for a flower pot an excavator would be an overkill.

For a software project there are several kind of tools that are used to build and document the project. One important category here is communication and collaboration tools. The typical enterprise collaboration tools is Microsoft Sharepoint or something equivalent, probably Jira. Many of the requirements architecture, design and deployment artifacts are shared between team members and with stakeholders using Sharepoint as a repository for documents, spreadsheets, diagrams, presentations. However the process of editing these artifacts requires a check-out of the file, updating it with some items and then checking it back so that other people can see the changes. This raises a problem because concurrent modifications to a file are hard to do as it involves some kind of merge at document level. Moreover, there are some tools that are not really designed to work in this manner and they have their own internal versioning mechanism (e.g. Sparx Enterprise Architect that is using a database in order to offer some concurrent access to the same model). Also you might need to have the same tool installed at every member of the project in order to effectively be able to contribute with changes so more licenses might hence the costs would rise up.

What I find interesting here would be to increase the collaboration value and lower the total cost of tooling. One excellent example is Wikipedia engine (Mediawiki) that permits thousands of simultaneous users that can read and change the content concurrently. This is also an interesting enterprise approach inside a team because a wiki engine works as a version control for the content it holds. Instead of adding word files it would be easier just to edit some wiki pages, where the edits and merges happen concurrently. Security rules and workflows can be enforced on a wiki. Sharepoint permits the creation of wiki pages so it enables this kind of collaboration. As the information is less constrained in long check-out, modify, check-in cycles it tends to stay more up to date.

How to treat diagrams in this case? In fact diagrams can be treated the same as other textual information. Tools like PlantUML can be used to render diagrams in real time starting from text representations. The text representations of diagrams can be written by any engineer or even extracted from existing code or infrastructure. This information would be quite up to date with the current state of the project and would benefit from all the advantages mentioned above: versioning, merges, etc. There can be even a reverse flow where diagrams can be obtained from code or deployed servers and containers thus documenting live state of systems.

When the content should be given outside the team it can be exported to PDF or another format keeping or even enhancing the format and appearance of the document. For an organization that embraces a devops culture this approach is inline with their philosophy. The documentation and collaboration is part of the production pipeline, is always deliverable and versioned. It can be integrated both in the CI/CD tools as well in the tools (extensions for Eclipse, Idea and Visual Studio are readily available).

The cost for such an approach might be very well close to zero especially when wikis or similar solutions are already in the company. This is not mutually exclusive with engineering solutions as Rational Rose, Enterprise Architect or even Visio. The latter are extraordinary tools with a broader scope than mere collaboration and information sharing as they enable model based development, code generation and other high end features. A lean approach would reduce a high upfront investment in tools and use the expensive licenses on a more rational way, the funds saved this way might be used to bring more value to the product.