There are plenty of ways to build software that responds to changes in data or outside events. It can be less intuitive to come up with a solution that needs to respond to nothing happening.
About a month ago I was co-host of the online conference Inclusive Design 24. This free 24 hour online conference focuses on inclusive design and shares knowledge and ideas from analogue to digital.
As a software engineer with a focus on architecture, my view on software inclusivity was very much focused on usability by people with different disabilities. These are very important considerations of course, but this is by no means the entire spectrum of inclusivity.
In this blog I will share my insights and thoughts on how we can take small steps in our day to day work that can make a huge impact on the inclusivity of our software.
Today I’ve been working exactly minus 23 days at JDriven. So as you might expect, officially I’ll be starting there at the first of July. For my new employer, this is no reason at all not to invite you on the seminars they provide for their people, so yes this proved as well there is a reason to make this next step into choosing for JDriven. So last Thursday there I headed to headquarters at Nieuwegein for a full day workshop about Microservices, given by nobody else than Sam Newman!
Sam Newman
Okay, for the ones who don’t know, he is the author of the books ’Building Microservices’, ’Lightweight Systems for Realtime Monitoring’, and the forthcoming book ’Monolith to Microservices’, all published by O’Reilly. He’s also known being the co-creator of the Lego XP Game.
"We’re agile! Just build it!" Or on the other hand; "agile does not support Software Architecture so we should stop doing agile". Two very different opinions that you can sometimes hear within the same company. Which one is right? Or are they both wrong? Should we stop doing architecture to be more agile? Why do we even need architecture? In this post I’ll give my view on the matter and hope to inspire you to combine Agile and Architecture in your organisation.
So what is Architecture? I like the quote by Ralph Johnson because it’s a clear and succinct definition:
Architecture is the decisions that you wish you could get right early in a project
Another quote I like that stresses the importance of thinking ahead:
Big design up front is dumb, but doing no design up front is even dumber
So, according to Johnson and Thomas we want to get some bits and pieces right early in the project. We do want to think ahead before we build something, but we don’t want to fall into the trap of designing a system that, by the time it’s built, won’t fit what the business needs anymore.
On the other hand we have an agile process where we need to deliver something 'of value' to the customer every couple of weeks. How do we reconcile these two, since sitting in front of a whiteboard for days doesn’t really produce anything of direct value to the customer?
While many of the architectural challenges we have to deal with are big hard choices, there are also many smaller simpler ones.
From "don’t call repository classes from controllers" to "don’t have cyclic dependencies". In most projects I’ve worked on these are unwritten rules. But why not write them down in a way that we can also see if the rules get broken? Can we test these rules?
The Thoughtworks Technology Radar is well known for showing technology trends and choices. For my project I wanted to have the same thing, not use the hosted public version from Thoughtworks, but a selfhosted option. Therefore I choose to base it on the Zalando opensource tech radar, and create a way to use a CSV file as input so updating would be an easy thing to do. To accomplish that I took the following steps:
Create a folder to put the tech radar into: ${project-folder}.
Start with the HTML5 Boilerplate index.html file and put it into the ${project-folder} file.
Insert the snippets as documented at Zalando Tech Radar, with one adjustment.
I don’t fill the entries array with entries, but will do that later on, from the input in the CSV file.
Note the names of the rings and quadrants, as they will be used in the next step, the CSV.
Create a CSV file (${project-folder}/data.csv) as input for the tech radar.
It has columns for the ring and quadrant where a technology should be put, and an indicator for movement.
The names of the rings and quadrant should equal those in the configuration copied from the Zalando example.
If you changed them, use those names instead.
The movement indicator is (up, none, down) and in the next step translated in to value understood by the radar.
The CSV will be translated into entries for the radar.
Add the following D3.js library to parse CSV:
This library provides functions to parse CSV file(s) into a map structure per row in the file.
Create a function to transform a row in the CSV into an entry for the tech radar:
This is the diversion from the steps in the Zalando tech radar description.
Wrap the radar_visualization() function a custom one, that takes an array of entry, to render the transformed rows, e.g. draw_radar(entries).
Finally glue everything together to fetch the CSV, parse and transform it, and draw the entries. The code below uses the functions I defined in the previous steps
When you have followed the above steps, the result should look like this:
As a software engineer you make architectural decisions all the time. Neal Ford calls these software engineers 'accidental architects'. I personally prefer the term implicit architects because I don’t think software engineers doing architecture is in any way an accident or even something you would not want. You’re the expert after all. Decision making is one thing though, how do you document these decisions?
In my current project my function title is Software Architect. I have mixed feelings about this. While it definitely looks good on a resume I actually don’t feel software architect is a function title. Software architect is in my opinion a role, and one that can’t be handled by someone that doesn’t have his or her’s boots on the ground where the software development happens.
This is reflected in many teams where there is an 'architect' that, every now and then, comes down from his golden throne in his lofty ivory tower to enlighten the code monkeys software engineers with his architecture. After enlightening the engineers he again ascends the thousand stairs to his throne to work on his next perfect work.
Another word for this is a seagull architecture; architects that, like seagulls, fly down cover everything with shit and then fly off again. Leaving the software engineers wondering what they did wrong in a previous life to deserve all this. And if you’re lucky you don’t have a single seagull to deal with, but a whole team of them with conflicting ideas on the direction your teams should take.
A low code approach to composing microservice architecture diagrams from per service context diagrams.
On a recent assignment I was one of multiple new engineers joining a start-up transitioning into a scale-up. The past two years had been spent rapidly developing to prove the concept, and while at the outset some diagrams were drawn up, at the time I joined these were outdated, lacking or even misleading. To help get ourselves and other new developers up to speed, Andrew Morgan and I set out to create architecture diagrams for the system as a whole.
Congratulations! Someone has made the wise decision to hire you as the new technical lead. It is an exciting time. You start in a new environment, will be working with a new team and maybe even have to learn new technologies along the way. This can be quite challenging. In this two-part article I want to share my personal views regarding Introducing change and shaping teams as a technical lead.
When starting in this new environment you probably bring lots of energy and want to leverage your experience to change things for the better. In my opinion introducing changes in a new environment requires some consideration.
In a previous post we learned how to use a together block to keep elements together.
We can also layout elements in a different way: using hidden lines.
We define our elements and by using the keyword [hidden] in our line definition the elements are layout as if there was a line, but we don’t see it.
This gives us great flexibility on how we layout our elements.
In the following sample we first have a PlantUML definition where we rely on the default layout:
Inspired by Neal Ford’s presentation at our Change is the Only constant event I started experimenting with architectural fitness functions. An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s). If you want to take a deeper dive into evolutionary architectures including fitness functions take look at Neals book: Building Evolutionary Architectures: Support Constant Change. Neal’s slides contained an example of verifying package dependencies from a Unit Test using JDepend.
In this blog post we’ll elaborate on that approach and create a Unit Test that verifies that our code complies to the chosen packaging strategies using an alternative to JDepend named code-assert. We’ll verify two types of packaging strategies; package by layer and package by feature. For a definition of these strategies please have a look at this blog from Simon Brown.
