Balance...

Being a developer with family is like trying to joggle with several balls  in the air. When one falls down the whole show is ruined.

In the past few days I was engaged in an activity at the local Waldorf school and I had to put work aside. Thankfully I work in a position where you have a chance to be flexible...in this case I decided to make up for the lost hours in the evenings and in the coming weeks...partly because I have eaten up my vacation days...but also because I need to feel that this is not vacation yet. The tasks were not delayed, and I managed to close all my Jira issues so everything seemed to be fine...besides the missed daily meetings.

Spending time with my family is a great thing and maximising this time is an important benefit, this type of job offers, besides the monetary remuneration...of course.

But on the other side...I love what I do and not being able to do it for a longer time creates a certain stress ... and I feel out of balance.

The planned vacations...those two weeks when you close shop...are the ones when I completely disconnect from work...and focus on resting and maximal enjoyment of life. In that period the balance is kept by other things...work is not part of the formula.


Things need to stay in balance...regardless what you do. Too much of something will affect the other areas...and things will fall apart.

Update...update...update

You can call it deployment or update, the idea is the same. You want to deliver your latest a greatest software to the rest of the world ... or just for your users...is a challenge you will face sooner or later.

Containerisation and tools like Kubernetes have solved the problem of orchestrating serverside application deployment and updates...so if you can (and it makes sense) bundle your app into a container...consider yourself lucky...DevOps will do the job for you...

...and Android / iOS apps are also covered thanks to the PlayStore and AppStore provided by Google and Apple.

...but for those who still develop desktop applications...huge things...that are not (or make no sense to be) bundled in containers because they run on the client machines...you might not be that lucky as pushing updates to machines you don't control, is not that easy...

I use CaptureOne for editing the photographs I take as an enthusiast hobbyist "photographer" and every time there is an update all the you get is a notification and link to donwload 150Mb of software...and run installers...hit Next..Next..Next....to get that new version.
The same goes for many applications... they just don't want to mess with the update systems...you...the user...should do the dirty job.

Thankfully the browsers (Chrome, Firefox...and I don't use anything else..the rest also probably) have figured it out how to get that update without asking you for download and install.


My latest task at the company I work for was to create an update system that would support all the products our department builds (desktop Java applications, RCP, SWT, Swing, and even headless Java apps)... all this with minimal user interference. It was a nice challenge...and it took a while until we figured it out how to do it in the less intrusive way...but in the end...I think it ended up great.
We learned a lot and that's also something important to keep in mind.

With this in place, at every sprint-end when we deliver new versions for each application we touch in a sprint, update packages are pushed automatically to the central repository and everyone will get the new version. A nice notification saying "Update is a available" and button that allows you to download the update in the background ... while you work ...and when is ready it prompts you for update...which is a matter of a simple restart. It will keep you settings, and everything you had so far...and you can continue working.

If you do Scrum and you commit to deliver every two weeks a piece of software, it is not enough to just build-it and store it somewhere...you have to make sure that it ends up on your clients machines.

That's when you can say...I completed an iteration.

Delivering the latest and greatest all the time...in the shortest period possible...allows the feedback to flow back to you...so you can react...and practice agility and respond to client demands.

Update is important...and it should be on your radar...it closes the cycle.

The rush for DevOps

DevOps became a buzzword and nowadays I feel that none understands it's true meaning...everyone wants to just do DevOps...but in their rush they end up inventing jobs and producing more work than solving problems.

For me, DevOps is the area when you combine development and coding with the software delivery and sometimes maintenance....and we live in a world when a true developer has to know the whole cycle...because that's how our world is ...fast and agile...where we need software out as fast as possible, there for the testers or the end users.

...but when your only job is to do DevOps, all you can think of is how many more steps you can add to the pipeline...and how you can use this or that plugin in the CI tools...and you tend to loose focus from the actual goal...remember? we are solving problems for our end users...with our products.

We have to find the balance...between too much DevOps and no DevOps at all.

When you end up having a DevOps team that is more than 20% of your actual development team than you might have to ask yourself some questions...and more so if that process you have in place for delivering software is so complex that none understands it...that's when you'll have too much DevOps.


Find your zen place and stay in balance...it does not matter what others think about your DevOps...until you deliver often and securely.

Raise your voice or stay quiet

There are sometimes things you hear in meetings that can push you to the edge of patience...like "there is no time for this now"...or "that was not planned"..."that's way too much to work, let's do this hack now and we'll come back to it later".

If your goal is to deliver the best product you can that serves your customers, these sentences will always make you angry. The question is do you speak out? ... do you raise your voice and share your concerns?


There are the situations when someone from the team comes with an idea of refactoring a part of a product...and although technically it could bring obvious benefits to the code structure.... but it just feels wrong...
The code he plans to refactor is working well...in production ...for so many years....and besides the nicer code, there is no added value for the end-user...it is something for us, developers...a nicer (trendy) framework...or just a different view of the same problem...but it gives us work...to fill that backlog.
...will you raise your voice?...and maybe convince the team that this is not beneficial on the long term?...although you probably would like to use that new framework....


...or there are case when someone, in it's rush to accomplish a task creates a new mini framework...because it is more fun and challenging to create than reuse...will you raise your voice?


...or when a customer is quite explicit on what it needs...and the management tries to steer that towards a product that is already in the portfolio, that's not quite the thing the customer wants...and delivering what the customer requested is a matter of few hours extra work...but the management tries to spare that work....will you raise your voice?

...and there are so many situations, when decisions don't make sense for you....will you raise your voice?


Almost in any any case, when you raise your voice and face up your superiors or colleagues on any objective topic, you will create waves...and depending on the company culture, the waves can be surfed upon or the'll create a tsunami you will fall victim of...

If the later is true, your are working for the wrong company.

Configuration vs Extension

When you develop a component that will be used by others, there is no chance to avoid the dilemma of taking the route of configurability or extendability.

Both options are tools for allowing customisation of the developed component...and there is a need for both.

Configuration can be a setting or parameter that changes the behaviour of a component, and such it is usually managed via configuration files or setters/getters on services.

Learning the different configuration options and combining them to something functional can be a daunting task...and is not always proportional with the development skills of one individual. 

The most common example for configuration are the different variations of loggers...log4j...commons.logging...java logging.... 

Extendability...if there is such a word...(or open of extension)...is when you get a basic functionality in the core library and you are allowed write code that extends the default functionality. For instance the Java collection framework is not very configurable but it can be extended to a great length...you can always write your own List or Map...hence the existence of he fastutil library.

Extendability is the O from SOLID principles.

Interestingly the trend imposed by Spring and similar frameworks goes in the direction of configurability ... and it's overwhelming .... just look at the amount of configuration options Spring boot (an application framework) has....out of the box...and those are only a few common ones...

...and on top of that add the annotations...that one million of them...with similar effect...just written in code.

Extendability is where developers work...and write code ...to extend functionality...or create a new one. That's where a skill is needed...to navigate the API and understand how a code works...to be able to extend it...and this is not learned fast.

Keeping track of all the options of a framework is a significant challenge...and is a form of technical debt...and while it is effective in creating applications fast...is it as effective when you need to maintain these applications?

Is this lexical knowledge the most important thing you are looking for in a job candidate? 

Why are you asking explicitly for Spring boot applications in those interview use-cases? ...how about just asking for an application that does the things you are interested in...and examine the skills one has in creating one...even if it will end up in a Spring boot application.

I know....there is no time for that...

Job interviews ... who are you looking for?

There is a shortage in software engineers...that's what they say... so in theory if you know your craft you should not be worried...the'll hire you.

A job interview is like a hurdle race, you have to sprint and jump over a ton of hurdles (tiny fences) and if you manage to do that they'll track the time. The fastest one to get to cross the finish line wins.

They have an open position and try to hire the best fitting person for that job. but the requirements are not clearly stated...they are looking for junior/medior/senior developers....with knowledge in a list of things... the more boxes you check the better they rank you...and that's it.


Some of us, don't care about titles...don't care about listing every piece of tech we touched in our CV...we just do our job...we stay humble and create great things...

I am not an expert in Spring, nor in Hibernate or Java EE, so if you are looking for a senior in these fields...no luck for me there...in your eyes I am an inexperienced...equal to a newbie who learned to code from Youtube.

...but when I say that I understand the concepts behind Spring...I mean it...and the same applies to the other frameworks....because I've seen so many things that nothing surprises me anymore....I learned to look behind the curtain...away from the stage light...where the corps are hidden...in the closet.

I don't just do things...I need to understand things...before I do them...I am a craftsman...



Who are you looking for? Experienced leaders or just doers?

Experienced people understand faster than newbies...as they have the context of the past...and will lift you up...they will not only fix your bugs...they'll fix you products...on the long term...and will teach the craft to the newbies...if you allow them....and create culture....but this takes time.

Start looking behind the curtain...called CV.

Are your tests enough?

When you develop an application, that has more that two features, it is calming to know that you have tests that can validate that the application is still functioning when you change something...at least some of you might have that feeling...or wish.

It is great to be able to balance over a safety-net, knowing that if you screw things up...you will not fall hard...the net will catch you...

If you work on products that have this...consider yourselves lucky...you bastards ...I envy you.
You, who do TDD by the book... and have written all the possible unit tests...and have all the coverage in the world...youuuuu...

Today we had a meeting about the raising concerns that although we strive to have as many regression tests as possible we still have a feeling that this is not enough...bugs can go unnoticed...and QA might be blamed for it... and consequences might be significant...
...and arguments were passed back and forth...and we agreed that there is no budget for this shit...cover it up...and back to work.

Something bugs my mind:
Let's assume that you have some tests...unit...or other functional tests...but automated.
How do you measure if you cover enough from the functionality of the product?
If you have several layers of APIs and and API surface as wide as ocean...a gazillion modules that each do something...but maybe not always used...how do you measure coverage?


If you can't measure coverage...you can't estimate the quality of your tests...regardless if they run for 3 hours straight...all you do is create the illusion of confidence by tests...nothing more.

Measuring coverage is not a simple task...as these days, Cobertura and friends are not your friends anymore...if you have almost no chance to do unit tests against your code...   (...and I'll let you scream all you want here...yes this is the case...)

All these "off-the-shelf" tools do, is instrument your code and measure how much did you touch from it during you tests...or runs...but if you have 10 million lines of code and the product is monster monolith...all these tools will report is an insignificant percent of coverage...that is almost impossible to get to a value that can be shown to management.

What about the API coverage? The API that is touched by the developers who build on top your monster...and dress it up in shiny skirts...to sell it to the unaware customers..

How do you measure coverage of a messaging API? How do you measure the code that is not purely functional?...it's OOP...remember...classes...hierarchies...dependencies...
Even Spring struggles with this...and all it does is it makes you end up with more code in src/test/java than in src/main/java .... but at least you have tests....check.


If you can't measure it... you walk blindfolded...in a dark room...full of venomous snakes...starved to near death.

Are your tests enough? Do you cover enough?

Short iterations...fast iterations ... feature flood

When you use a product, its nice to have frequent updates...fixes...features.

...but when you develop a product based on a framework, you expect the contrary...

When you build a house you would like to have the most stable foundation...but not the most complex one...the one that fulfils the needs...nothing more.

If you build a framework ... using scrum...than every iteration you deliver a product increment...something new...something better... a new foundation....

This process is good for you, as a framework developer...but for the users it creates a constant pressure to update...and with every update the chance of regression...but if you don't update...you fall behind.

Slow down...you are killing us.

Solving problems or building products

Most software products started from solving user problems....scratching an itch...or two

If you find a persisting itch that you can scratch than you are lucky...and thankfully there are so many itches....

The technology has come so far that nowdays building a pruduct is trivial...and commoditised....and everyone builds a product...writes a framework...and vlogs about it...brags about it on social media....they show off...

"...uh I'm so good...look at me...I made this"

...but people who know their craft can see through this facade....they know that creating something new is the smallest part of our business...

A car painter does not paint cars just for the fun of it....it paints the cars of people who need this service. This does not make him less skilled or less of a painter...

Or as a gardener does not plant seeds to every green spot it finds...does not grow plants everywhere...only where it knows that what it does is meaningfull....will create an impact.

Why can't we, software developers be like painters or gardeners.... don't build stuff for the purpose of showing off...we know you are skilled and companies hiring you will cherish you...if you deserve it.

Everyone can use a framework...can follow instructions... that's not creativity.... that's obedience... that's mediocre. 

Learn the craft of building software...and stand out creating meaningfull stuff...not by creating abundance of mediocre shit.

Solve the problems don't just build products..

Are you a fanboy?

Fanboys are hard to argue with... the seem possessed.

I am sure you met someone who is obsessed with a certain framework, and all they can see is "how beautiful" that technology is. and that it solves every problem...it's a silver bullet... they are in love.

There is no sens to argue with them...you will always loose...maybe not in the argument...but for sure your relationship will suffer.

The wiser are not fanboys...they always look at the big picture...and don't go all-in into a technology.

Probably it is better if you choose to stay on both of your feet...use one technology but always keep an eye on the others....mix and match....the truth is always in the middle.

Are you a fanboy?

...I used to be...but than I matured...I guess ;)

Disclaimer: please don't get this as an insult, please consider this gender neutral.

There is always another way...

We are problem solvers...with software.

Everyday we go to work to address some issues, solve problems, somebody else's problems, but that's our job....that's what we do best.

Every problem has multiple solutions, different algorithms, different constructs, different frameworks...and usually similar results.

Some solutions are better than others, so there is always a challenge to choose the best solution... you never know which road to take.

Some of us are more conservative and others are more open to new and keeping things in balance is hard work, requires attention and care...so how do you do it?

If I need to make a change I ask myself these questions:

- am I satisfied with this change? did I give my best in doing the change?

- is this covering and solving every (or most of the) use-case?

- will someone be able to understand and maintain this in a year from now?

On a crossroads of deciding for a framework / technology I consider the following:

- do I understand the new fwk/technology enough to develop in/on top of it?

- will this technology be alive in 2 years (if the project lives at least that long)?

- how much experience does the team have (in case you work in a team) in that fwk/technology? can we learn fast enough?

- do you have a solution in case something goes wrong due to the fwk/technology? how fast can you act?

- is this an exclusive technology or can be used in combination with others? 

Jumping to the shiniest, new thing, trending these days, might be fun but will it always benefit us? 

...or you will just work fancier...so that you can add this to your CV? 

Should I make selfish decisions or always comply with the project? 

There is always another way...and people will sometimes force you to accept their solution (because it's shiny or because everyone does it like that, or just because they said so), but you can always say no. 

Trust your gut, and if that does not give an answer ask yourself some questions, make a decision and take responsibility for it.

Scrum - perils of the treadwheel

Keep your head down and work....that's what they used to say. ...no comments allowed...

Fortunately these times have passed and now you have the freedom of speech and you can raise your voice whenever you feel so...we live in a democracy (at least in the development world)...theoretically.


Agile practices have been invented to address the concerns of slowness and bureaucracy in the software development process. They focus on creating a clear view on what needs to be done and also they facilitate the communication between the team members and everyone involved in a project. So you can ask questions, raise concerns...but besides that you keep your head down and focus on the backlog.


The authoritarian roles (Architects, Project managers, ....) in the development have been replaced by democratic processes involving everyone. We strive for democracy.

With agile, and Scrum in particular, there is no single point of failure in a project anymore.... everyone is equal...and mediocre in the same time.
Regardless of your expertise, you have a voice...and that's freedom of speech.


Scrum makes you eat up the backlog one sprint at a time (divide and conquer).
If you fail to complete, you are little bit shamed by the not so optimal burn-down chart...but you will start over...you get a new chance....with a new backlog.
You learn to to keep your eyes only on the sprint backlog...that's only what matters now...for two weeks.


But what about the strategy? What happens to the long term goals of a project? Is a team capable to agree on a strategy and follow through? Who decides the strategy?

If you keep your head buried in the backlog, there is no time for strategic thinking...it's not in the backlog...you should not care.

A bit like factory workers...you have a voice but you learn that it does not change anything.


Every great achievement in the human history was achieved with a leader...and a great team that followed him. There is always a leader.

Should Agile teams democratically elect a leader? ... that could focus on strategy ... and future ...and could fight the battles...and lead the way... or should we leave this to the Product Owner?

Who is a Java developer - and does anyone care?

There was a time when programmers were good in one (maybe more) particular programming language, and they called themselves XYZ developer/programmer.
All that meant that someone can solve problems with a particular language.

Java, the language, is not that complicated and the syntax can be learned pretty fast. But knowing the syntax is enough to call yourself a Java developer? ...well not really.
As a Java developer you should be familiar with the framework of Java, the classes and features included into the standard Java runtime (the one you get when you install Java). And things get worse, as besides the Standard Edition (SE) there is Enterprise Edition (EE) with even bigger set of features to be learned. ...an that my friend, takes time and practice.

Assuming that you spent significant time with Java SE and you used most of it's features (you know the collections framework, the IO / NIO, the concurrency, ...all of them), are you a Java developer?
If you have spent let's say 14 years working with Java, are you a Java developer? ...are you a senior one?

...well my friend, you might be, but does anyone care? My experience is that not really...
Companies (at least most of them) are not looking for Java developers, although that's what they claim in Job postings, but that's a trap. Pretty fast you will realise that all they want is someone decent enough in Java but experienced in using one particular framework. So you have to keep learning and as you enter the rabbit hole there is no turning back. Choose wise which hole you pick.

Learning Spring these days, is almost equivalent to learning Java SE and as you go deeper and deeper you get infected with everything that's not Java anymore. You get used to things like @Autowired, @Component and @Bean and than if you get the Lombok virus you get @Data @Value @Log4j2 @Builder ...and than come AOP and all those shiny things that make you more productive and in the same time more....more stupid and ignorant. 

-Am I a Java developer?
I tend to say I am.

-Does anyone care?
...not really, unless I learn all the possible annotations and annotation combinations of a framework....than I can become a Java developer...for some.

Do you feel the trap here?


Think about it,
are you a Java developer or a framework user that happens to code in Java?



Disclaimer: I picked Spring just as an example, knowing that almost everyone in the Java space knows what Spring is, but you could replace Spring wit any of the following: JBoss, Eclipse RCP, Hibernate, Vaadin, Struts....and more.

Uh I feel old...

I consider myself a Software Craftsman. one that focuses on the problem and tries to solve it with the best tool it has at his disposal, and with which he can confidently provide quality.
This means that I don't shy away from using older technologies as long as those solve the problem and are reasonably mature to serve until it is needed...and being used to look at the big picture I can leverage using any framework for the task.

The problem is that the world has grown in a different way.
The abundance of frameworks has shaped the IT landscape and the job requirements of Today. Nowadays one who knows how to use (program in) a framework has advantage over anyone having a broader knowledge and significantly more experience in delivering and maintaining software.
And this is because companies expect the newcomer to quickly become productive (in complying with the framework). They need a Java / Spring boot developer, a Javascript / React developer, an Angular developer...

...but what if you have no experience with the particular framework, you already lost. Nobody cares if are capable to learn and work with that framework...if you don't know it, you are not our guy. We don't have time to wait for you to learn...we don't feel that you are the best candidate for us.

I don't get it.
When you take your car to the repair shop, you want someone who knows what he/she is doing, right? ...is good in his craft...is confident..because he has been through thing, fixed some cars.
...or would you trust a newbie with fancy/shiny tools and clean shirt instead?