Does it even make sense to write blog posts in the AI era? With few notes some common AI tool can generate pages of excellently written text using the purest Cambridge English. Such tool was used to help me to tune even these lines.

However, what AI still cannot do is to transfer experience. And that is what you will find in this blog post.

I’ve been working on UI component libraries and design systems for more than 5 years now and after completing my most recent project, I decided to write few useful tips for anybody, especially developers, who may find themselves struggling with common design system challenges, or, like myself, frontend development efficiency challenges.

Episode 1: Talk to the Decision-Makers

The efficiency challenges that my previous organization faced were:

• requirements on costly pixel-perfect look & feel early on
• uncertainty whether the end users will actually appreciate the pixel-perfect frontend in a way that would reflect in the company’s revenue
• disregarding the value (look & feel and behavior) of the underlying 3rd party UI component library (Angular Material) and constant requests to override it

These requirements were mostly coming from the business and design departments. Even though we were using Angular Material, the business and design were never quite satisfied with the look & feel and the features of the components this library was providing; they wanted buttons smaller, text bolder, colors a few shades different — you name it.

Design system or even a simple UI component library is supposed to improve efficiency. That’s where we, as part of the design system / UI component library team come in. We’re here to keep things efficient and sensible.

Therefore, the first lesson I’ve learned is how and who to speak to when you feel your organization may be using its resources ineffectively on unnecessary frontend development and maintenance.

So, what can we do to save our organization some money?

First off, let’s talk about these issues early enough with the decision-makers — the folks who hold the purse strings.

What we need to do is to show the decision-makers some hard numbers and ask if all that initial look & feel tinkering is really worth it in the end. The hard numbers part — that is sometimes the hardest part. Only tool we’ll have in our hands is our ability to estimate.

How to estimate CSS overrides?

What I’ve learned is that every line of CSS overriding styles in the underlying UI component library, although it may seem like a simple task, is actually quite expensive. To understand why, we must consider that:

• You must figure out what exact style of what exact element inside a component is different in the design from your designer than in the library. This often involves lengthy discussions with them, lasting several minutes.
• Then you must find the place in that UI component library where the style rule is written. That includes searching in the files in the repository of your UI component library and studying its CSS.
• Then you must write stronger selector.
• Then you must rethink and refactor everything in order to write as optimal, clean, readable, changeable CSS as possible.

A good rule of thumb is to allocate at least one hour of estimated time for each style or line of overridden CSS code.

If this still sounds like too much, we can go back to my previous project, where the design department was not satisfied with the look & feel even of the simplest component — the button.

They required to change internal paddings, font size, line height, background color shade (even though it was still red, but they wanted different red), the hover effect visualization opacity, the focus state background color shade…in the end, it was still a button, but with 200 lines of overriding CSS!

Estimate a minimum of one hour for each style or line of overridden CSS code.

It took us several full days of work initially, and we also had to dedicate additional time to maintaining the overridden CSS over the next phasis of the project.

Additional costs of CSS overriding — do the users actually need it?

The method of CSS customization we demonstrated isn’t just expensive and unproven in its value to users, but it’s also risky.

First off, the styling of the underlying UI component library could change at any time. Developers of the library might alter CSS class names, style properties, or even the entire internal DOM structure of the components.

This means that every library upgrade puts our custom styles at risk of becoming obsolete.

Secondly, we’re uncertain whether end users will be willing to pay for any developed feature, not just those involving CSS overriding. To gain insight into this, we must do research, prototyping, usability testing, and later analyze the gathered user data, opinions, and responses. Based on this analysis, we’ll make decisions on further development. However, this is a whole other topic that extends beyond the scope of this blog post.

What are typical business-design-development dynamics?

The problem is that in our daily work within our teams, sometimes we butt heads for too long with our analysts and designers. Especially when even after weeks or months of trying, there is no significant change in the mindset and requirements for overriding underlying UI component library still appear in the sprints.

I used to hear from analysts and designers that Angular Material does not fulfil our needs and looks too much like a Google product (well, it is a Google product).

I used to tell them that we should prioritize completing a version of the application using the Angular Material as it was, and focus rather on the functionality our end users require and are willing to pay for, before achieving pixel-perfection.

Don’t take me wrong, usually the analysts and designers intentions are noble, driven by a desire to please and fulfill organization goals. However, sometimes they’re shooting for the moon without considering the costs. Chasing pixel-perfect designs ends up costing a fortune and slowing things down. And sometimes the upper management or even CEO themselves do not consider the costs, which is contraindicative to our goal to save (and earn!) some funds on unimportant frontend development.

To emphasize the advice earlier, what we have to do in order to help our organization is stand up, arrange a meeting with the relevant decision-maker, and discuss the inefficiencies we’ve identified, along with suggestions for improvement. Do what we can to agree on limiting the excessive demands for changes to the underlying UI component library’s look and feel.

What would I advice to my a bit younger self?

Maybe you ask now: did this guy really not know such an obvious truth? I agree. It does sound obvious. But despite knowing this, I kept on writing code and discussing the issues within my team, but didn’t take any further action.

What I could do better instead of focusing on my role as a developer was embracing more my role as a consultant. Just imagine if I had expressed my doubts to the right person earlier. I actually did that after my project ended… and the they were receptive to my ideas and took my concerns about inefficient development seriously. Particularly when I demonstrated the considerable funds we had squandered in this manner.

Therefore, this blog post is aimed to encourage people to actually make the difference in their project and enable their team and product to success (for example applying advices from this blog post).

This time I had been just too much of a developer and too little of an innovation enabler.

Key takeaways

1. Avoid prolonged debates with analysts and designers regarding the customization of underlying UI component library.
2. Speak directly with decision-makers and illustrate the financial consequences of overriding components.
3. Acknowledge that every line of overridden CSS code demands at least one hour of work.

What’s next?

In the next episode, we’ll tackle risk management. What if, even after laying out the costs of tweaking UI components and chasing pixel-perfection, even the CEO insists that look & feel take precedence? This puts the project in danger, as our custom overriding CSS is vulnerable to upgrades of underlying UI components library. As design system developers, we need to find ways to handle it.

But, before we dive into that, learn from my mistake and take action now: make sure to schedule that meeting with the right person to save your organization some cash!

“It’s just one line in CSS” is how organizations bleed their money was originally published in ableneo tech & transformation on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous article, we discussed one practical way of applying SOLID principles in projects.

SOLID principles beyond theory

Today, we would like to discuss the SOLID principles' benefits. About their pros and cons and about, the change they bring to projects => about their impact.

In general, we can observe 3 areas of impact:

• system stability
• faster delivery & onboarding
• overhead

System Stability

One of the main benefits of using the SOLID principles is that they help to ensure that global changes do not require changes to all applications. This improves system stability, as the system is harder to break.

We could say the system now has more “legs” — modules, classes, and interfaces created to be SOLID-compliant.

For instance, imagine a situation when we’ve just implemented a Façade pattern to ensure our classes have only Single Responsibility.

Now, when we break something in one class that implements the Façade interface, the others stand still.

Additionally, a stable system is more likely to fail during build than in runtime. For example, when we change a method signature in our Façade interface, we immediately notice we must adjust the implementations of that method. On the contrary, if we don’t separate the responsibilities using a Façade, adding another switch case to the existing method could influence its consumers in an unwanted, error-prone way.

It provides stakeholders with greater confidence in the system when it fails less in the runtime.

Faster Delivery & Onboarding

The SOLID principles also help to increase the speed of delivery due to improved code readability.

It’s like a carpenter using well-crafted tools to build a house. The carpenter can work faster and more efficiently if the tools are sharp and well-maintained and when he knows them well. Similarly, when software developer applies the SOLID principles to their code, it makes the code more organized and understandable — allowing the developers to work faster and more efficiently.

In other words, SOLID principles reduce the risk of the infamous spaghetti code occurrence, which leads to the reduced amount of (onboarding) time it takes for new developers to become accustomed to the codebase and to gain such a level so they break stuff less often.

Better code readability is also beneficial as it means that a high level of expertise from the developers is no longer critical (e.g. before seniors only, now also mid-level).

The result can be faster development since writing properly the classes, modules, and interfaces to make the code more readable gives developers more detailed knowledge about the system.

Additionally, the development experience is improved, as there is less boilerplate code to write in the “client” side of the code — the code that uses our SOLID-compliant system implements its interfaces, etc. It makes life easier for the other developers — consumers of our code.

Overhead

It should be noted that overhead is associated with applying the SOLID principles. This can include the cost of creating the interfaces, classes, and modules and the cost associated with evangelizing and educating developers on the principles.

However, in the long run, these costs can be offset by the time and resources saved due to the previously mentioned improved system stability and code readability.

Who and when will notice the change?

To measure the impact of SOLID principles, we could focus on key roles and how they perceive the changes in the project after the intentional application of SOLID. The key roles are: the (other) developers, tech-lead(s) (or senior developers, if you will), testers, and managers, and they could notice the change at these moments:

• Developers will notice the change at code review when they realize that the code is now not as straightforward as it used to be due to the additional “layers” (classes, interfaces, modules).
• Tech-lead(s) will notice the change when the new developers need a shorter time to produce changes without breaking the system.
• Testers will notice the change when the previously very buggy part of the system is now less buggy.
• Managers will notice the change when the feature that was expensive to change is now less expensive.
• Managers will notice the impact when developers present at the retro that they are happy with the benefits regarding the development experience that the SOLID principles have brought in the last sprints.
• Managers will notice when some system that was regularly a central topic in the management meetings before releases suddenly is not. Nobody is scared anymore that it will fail and that customers will complain.

Summary — the impact of SOLID

• Global changes do not mean the necessity to change all applications
• The system is harder to break (it has more “legs”: the modules, classes, and interfaces)
• The system fails instead a during build than in runtime
• Less worried stakeholders
• The high expertise of the developers is no longer critical (before seniors, now also mid-level)
• Better development experience, less boilerplate in the client’s code
• Faster development because writing interfaces, classes, and modules in the correct SOLID-compliant way gives developers more detailed knowledge about the system
• Shorter onboarding time
• Shorter time until the new developers are mature enough, so they break something less often.
• Creation of the interfaces and modules has its cost but saves resources in the future.
• Evangelization and education about SOLID have its cost. It is an investment in human resources through

Bonus — what should a software crafter do to write SOLID-compliant code?

To conclude our two SOLID articles, these are our recommendations for anybody keen to write stable, maintainable code that works and brings results to the clients or to the world:

A SOLID-compliant software crafter should be able to understand the theory behind the SOLID principles and be able to use them to solve real project problems or to improve something.

They should be able to connect the solutions with the theory of SOLID principles, as well as have the argumentation (rhetoric) to explain the benefits to the stakeholders.

Additionally, they should follow the SOLID principles when writing their “daily” code and keep the system in compliance with them, as well as educate their teammates, suggest improvements, and be able to deliver them.

Finally, they should repeat this cycle to achieve a long-lasting stable impact on the project.

My thanks go to my exceptional colleagues @Pawel Kruszewski , Mato Ďuriš & Matej Kolečáni, who helped me to craft this blog :)

Impact of SOLID principles in projects was originally published in ableneo tech & transformation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most of us have probably heard about them, read them, or even learned about them at University. They are considered the “basic building blocks” of any sane software project, the “guardian angel” of maintainability. However, SOLID principles are not something we, including myself, would like to keep memorized. At least not the exact wordings of them.

For example, the ‘L’ in the acronym refers to the ‘Liskov substitution principle’. This is the wording from the original paper:

Liskov substitution principle - Wikipedia

Even after studying the principle quite deeply, when reading the statement, I must stop at every word and ‘digest’ it to understand again the logic behind it.

Other principles wordings are more or less similar and, therefore, hard to understand at first glance.

If the SOLID principles are so deeply theoretical, is there any practical way how we could apply them in real projects, so we are able to benefit from their potential?

After several hours of consultations with my experienced colleagues at ableneo, and after I saw the SOLID principles videos of Robert Martin’s Clean Coders, I will try to describe one possibility of a practical SOLID attitude.

Clean Coders : Level up your code.

The motivation to speak about SOLID and software quality, in general, is, in my opinion, the significant risk that a project fails to the costs of changes. SOLID principles can help to avoid this scenario because SOLID principles keep the primary value (a.k.a. ‘softness’ or changeability) of software high (besides that, the secondary value of software is the current behavior of the software or its ‘features’).

In other words, if we want to work on more meaningful projects with more impact, more added value, more fun, more economic success, and more everything, we as developers must protect and iteratively improve the primary value of the software. Even when there is the infamous ‘pressure on delivery’, we still take responsibility for the quality and maintainability of the code we produce. Especially in long-term projects.

Therefore, to be SOLID compliant, an initiative from the developers’ (or Software Crafters’, if you will) side is required (solving problems using SOLID, bringing benefits with SOLID, and speaking about them).

In an ideal world, the goal is to live the principles daily. We want the team to have the principles in the back of their heads and to use them instinctively. We don’t need people to be able to cite the exact wording of the principles at midnight.

We achieve this, which may now sound obvious, by regular public speaking about good patterns and how we fixed the bad ones using SOLID. For example, on a technology workshop, an ad-hoc call, a Pair / Mob Programming session, or during a code review.

I emphasize the importance of speaking about the benefits we achieved by the application of a SOLID principle and what problems we solved or avoided. It is recommended not to start with a technical description such as: “hey guys, have you heard about the Interface Segregation principle? It goes like this: no code should be forced to…, and I think we should start applying it.” We can rather mention later after the work is done, what principle was used.

In conclusion, my golden rule for SOLID principles I’m trying to stick to is:

SOLID principles should be indirectly and instinctively used by individuals or teams as a good habit that brings benefits, not as a directly enforced rule (just like Pair Programming).

And now, when we use SOLID instinctively, it would be interesting to look at the impact of SOLID principles and possibly improve it! How could we do this? Well, one way is to be “able to measure it” — if we can measure it, we can compare it — hence be able to evaluate the change afterwards. We are working on this, and in the following articles, we will discuss the impact of SOLID principles on projects and how to measure & evaluate & improve the “SOLID instincts”.

SOLID principles beyond theory was originally published in ableneo tech & transformation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Did you know about one of the unhappy and controversial effects of long internet discussions, known as Godwin’s law? Long story short, it claims that:

“The longer the discussion, the higher the probability somebody mentions Nazis”

Unfortunately, such a mathematical formula truly exists.

To answer my rhetorical question from the subtitle: no, thank god, Code Reviews are a set of comments and discussions where this law does not apply 🙂.

However, like internet and social media discussions, Code Reviews can be LOOOOOONG. Many of us have such an experience: a sprint starts, our colleague makes a coffee, we take a task and start developing a new feature. First half of the sprint passes and thefirst “draft” Pull Request is created. And then it starts…

“Wouldn’t bar be a better name? No, I think foo describes it better. This method is way too long, can you split it? Please write tests for this class, it’s not covered. This library is deprecated, can you use the alternative one? Could you please…???”

Suddenly, after multiple Code Reviews with fixing andrefactoring iterations we realize the end of the sprint is coming and our QA staff will have to (again) work overtime to be able to test the feature before it goes to production.

Even though we want our developer teams’ knowledge shared, and to avoid knowledge silos and to ensure the quality of our code, and it’s really convenient to work fully remotely, the tool we often use for these — Code Reviews — can be ineffective.

This story happened recently on my project at Solargis, our innovative client at ableneo. A new senior developer came and one of his first tasks was to implement a rather complex, reusable UX/UI component. It was doable within one sprint, although significantly complex, but he was a senior, right? He should be able to do it and in case he implements something not according the team standards, other developers will point it out in their Code Review. However, the task was so complicated, the new developer (of course not his fault) was so unaware of the team code standards and requirements that after some time the number of comments in the Pull Request grew enormously. Additionally, since he was a senior, he had reasonable answers for the comments and explanations why he had developed something in a particular way.

All these factors resulted in not delivering the feature until the end of the sprint. After the sprint the priorities had changed and the Pull Request is still hanging in the team’s repository as this article is being published.🙃

So, how can we make the Code Review more effective and still utilize the benefits of inter-developer communication about the code they write day to day?

It’s simple: do not do Code Reviews 🙂

Or at least: do not do the majority of Code Reviews in the form of an internet discussion under a line of code.

Why would we write everything when we can just say everything? Ask everything? Directly consult anything?

This is when our good old friend, the Extreme Programming technique Pair Programming comes into the fore.

It’s an engineering practice recommended by authorities like Robert Martin or Martin Fowler to help the teams and the individuals to be on the same page.

Uncle Bob Martin on Twitter: "The true value of pair (or mob) programming is that it allows knowledge to spread quickly through the team. This shared knowledge is what makes the team a team. In a team, when a player goes down, the others cover the hole and keep moving towards the goal. / Twitter"

The true value of pair (or mob) programming is that it allows knowledge to spread quickly through the team. This shared knowledge is what makes the team a team. In a team, when a player goes down, the others cover the hole and keep moving towards the goal.

However, this article is not so much about what actually is Pair Programming and how to do it, but rather why to do it and what consequences it had in a real project.

At the same time of our unsuccessful delivery of our List component, we realized we have to face these challenges:

• Pull Request bottlenecks (undelivered List component)
• Dispersion due to pandemic remote work
• No onboarding process
• Knowledge silos (long-term employees with busy calendars)

All our collaboration work was happening in the Code Reviews, ad-hoc 1:1 or 1:N calls, so there was definitely teamwork. But why don’t improve it and standardize it?

We could see Pair Programming really addresses most of our problems when we looked at the benefits:

• knowledge sharing
• keeping focus on what is important
• reflection
• Code Review on-the-go (catching errors and bad design early)
• avoidance of superficial Code Reviews (“looks good to me”)
• avoidance of Code Review bottlenecks
• team building on-the-go
• tactical & strategical points of view at the same time
• collective code ownership
• faster and more effective onboarding of new team members
• avoidance of sunk-cost-fallacy (motivation to improve something gets weaker with time)

So, we decided to make an experiment: let’s pair by default for one sprint (in our case 3 weeks).

First, we agreed what type of tasks are suitable for pairing:

• complex code with unknown / unclear solutions (with prior research)
• volatile sections of the system
• critical systems
• core libraries

And what not:

• trivial tasks
• spikes, proof of concepts

Then, we decided who should pair with whom: senior-junior or junior-junior pairs make more sense than senior-senior from the knowledge sharing point of view.

Finally, the team set its measurement technique. Even though there are some studies that had attempted to measure effects of Pair Programming mathematically and compare it with individual programming, it’s another challenge to apply these measurements in non-laboratory conditions. Due to this we decided our measurement technique will be the team’s feelings and feedback after the experiment.

And that went quite well. At the retro after the sprint ended, among our approximately 10 team members, 6 reflected positively about our experiment.

One of my colleagues was so kind that he even wrote a complex feedback on his experience with pairing:

Went well:

I could think out loud

I could practice what I already know

I was corrected and received explanation when I said something incorrect

I received hints when I got stuck

I could see how the other person thinks, what tools they use and that helped me to optimize my work

Pair Programming has a benefit of instant meeting with my colleagues

To Improve:

I got disturbed when there are other people talking around my desk, because during the pandemic I was used to work alone

At the beginning it felt awkward to talk in front of other people, but later I got used to it

I did not have enough time to write what I learned from the other person and I kept forgetting it

After the experiment, the team realized that Pair Programming should be adopted as a new standard and since then, we pair on a daily basis. However, in order to do Pair Programming in a sustainable manner, there are some challenges that have to be solved:

Challenge: exhaustion (coding + communication = two tasks that require energy)

Solution: breaks, pairing for limited part of the day

Challenge: differences in coding styles

Solution: invest time to understanding, ask questions: how do we want to pair? give / receive feedback after the session

Challenge: interruptions caused by meetings, little individual time

Solution: proper planning

Challenge: losing focus

Solution: do not do anything else, no mobile phones

Challenge: different skill levels

Solution: it’s an opportunity to test more experienced developer’s abilities to explain, the less experienced can still see something what the more experienced may not

Challenge: power dynamics

Solution: be humble, be vulnerable, no keyboard hogging, no micro-management, let the other finish their thoughts (5 second rule)

Challenge: pairing when there are lots of unknowns

Solution: do spikes individually, make notes when you encounter unclear problems during the session

Challenge: confrontations about the effectivity of Pair Programming

Solution: patiently explain the benefits (maybe with this article 😎), show data, studies and community opinions, do an experiment and receive team’s feedback

Typical situation:

Business stakeholder: “Pair-Programming halves the productivity of developers.”

Martin Fowler: “That would be true if the hardest part of programming was typing”.

In conclusion, humans are social creatures. Even though part of the society can still perceive Software Developers as rather introverted people, I don’t believe it’s generally true. What I believe is that software development is by its nature team-based work. Therefore, Pair Programming is a great technique that can bring your programming & personal skills to the next level.

So, see you at our common desk. 😉

How to make Code Review more effective with Pair Programming was originally published in ableneo People on Medium, where people are continuing the conversation by highlighting and responding to this story.

I must admit: one of the best decisions in my life was not made fully by me, but also by my parents.

When I was 17, they advised me to join my brother and study Information Technology at the same university. I did not know then, thanks to them, I will find the best possible match among my profession, lifestyle and personality.

Me, coming from a non-specific academically oriented grammar school with tones of geography, biology, chemistry, etc., starting my first semester at University → I had no clue what programming is. Oh yeah, I already knew some languages exist! Like English, German, Spanish…

Nevertheless, after the first year, full of frustration and thoughts on giving up, I started to love my field of study, especially app programming (it’s the same feeling as when you’re 10 and building your biggest, coolest most super-duper Lego hovercraft!)

My little successes of developing a plain HTML CRUD app led me to my first job at a big corporate. This is when the magic started. Assumptions were low: I’m gonna sit in the office every day for many years, doing basic work and trying to be at least somehow helpful to my bosses with such big expectations on me (like making-a-coffee-for-them helpful)

However, one day I found an email, coming from our high management, saying: Ok guys, we’re reducing our costs for office space rental so from now on every working day 20% of you will work from home.

Wait, what? Like there won’t be a boss standing behind my back for 8 hours every day? Like apart from scheduled meetings, I can work 4 hours in the morning, then go running when the sun is up (I know, programmers, like vampires, do not like sun, but anyway, moving on…) and later finish the second half during the evening? Wow! Side note: this was in 2015 when the global pandemic was appearing only in movies that usually included some zombie fighting.

I could not believe that. And it made me kind-of pampered 😎 because that time it was far from being a standard.

A few years later I joined ableneo and I realized the flexibility can be even higher in a middle-sized consultancy with the right attitude. Was it possible to work rather 12 hours a day and then go on six two week holidays in one year? Yes. Did I move to Australia for a year and then rejoined ableneo like nothing happened? Yes. Could I extend my holiday at Canary Islands and later start to work remotely because I felt like surfing more? True (also thanks to our respected customer Solargis who has the best green-energy-solar-photovoltaic-prediction-forecast-whatever data and apps ever and it’s an honour to work for them). Was it possible to reserve 3 flexible holiday days in one sprint so my ski buddies and me could watch weather every day and choose the best one regarding the snow conditions? Also, true. And I could continue…

Now stop being selfish: this entire flexibility is not only beneficial for the YOLO part of myself, but also for my employer and clients. I’ll give you an example: last week before my planned holiday I’m counting the days to finish my work. Later, on the last days of my break I can’t wait to start working and building things again. I sense that my batteries are not just recharged, but literally so full of energy that they could explode! And then they explode in coding, so the impact is generally bigger than it would be if I worked in less flexible environment. Besides that, I feel way more motivated with the vision of a holiday or trip every few months in front of me. It really gets me up every morning and dare to write that one more unit test, to tell that one more honest estimation of a new feature to fulfill client’s road map…

Dear ladies and gentlemen, people who want to feel impact in their work while maintaining the other parts of their lives, if there’s any field in the 21st. century where you can combine career, a high standard of living, flexibility and family, it’s IT. Just like me, you can take the advantage of this flexible environment to cover your needs while staying motivated and productive. Don’t worry you’re not technical, because it’s creative! Don’t worry you will work with no living people, only with machines, because I can show you my calendar full of meetings, ceremonies and brainstormings! Well, sometimes maybe too full…but we can do it!

In conclusion I can only say I’m grateful. For the flexibility, for the “found my purpose” feeling, for the impact, for those cool things 🏄 🏝️⛷️⛰️ I can enjoy while still doing my beloved work: software development 👨‍💻.

Let me surf, ski and code was originally published in ableneo People on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some time ago my colleague, #innovationenabler and CTO of ableneo, Gustav Novotný recommended to me some of Robert Martin’s (Uncle Bob’s) conference speeches about Clean Code. It’s quite long (10 hours), free to watch on YouTube (the conference is called UnityCoin so credits to them) and has 6 parts:

• 1 (Clean Code): https://www.youtube.com/watch?v=7EmboKQH8lM
• 2 (Clean Code): https://www.youtube.com/watch?v=2a_ytyt9sf8
• 3 (Software Engineering Professionalism): https://www.youtube.com/watch?v=Qjywrq2gM8o
• 4 (Test Driven Development): https://www.youtube.com/watch?v=58jGpV2Cg50&t=2442s
• 5 (Clean Architecture): https://www.youtube.com/watch?v=sn0aFEMVTpA&t=2
• 6 (Agile): https://www.youtube.com/watch?v=l-gF0vDhJVI&t=3714s

As you can see, the topic of these speeches is not just Clean Code. It was way broader and included other topics such as testing, architecture and agile.

Together, all these quality assurance aspects of a good code and professional software development form an approach named Software Craftsmanship, which Robert Martin is co-creator of (as well as Agile).

To be honest, I was watching the conference breathlessly with my eyes widely opened. Maybe it was Uncle Bob’s entertaining way of presenting such a “geeky” thing software development is, but mainly because I really saw a big added value for me in his speech.

On the other hand, I was surprised — if all these Software Craftsmanship rules, that were invented by great minds of our field, are so important and valuable, why do we hear about them so rarely in projects, even from senior developers?

I need to say, that really — Robert Martin talks about Clean Code, Professionalism and Testing principles so clearly that I feel it’s pointless for me to re-phrase them. This is why you will see me quoting him and giving examples after him.

I’ve compared my feelings, challenges and experience with other software developers that I worked with on several projects in Europe and Australia. Unfortunately, a vast majority told me that the only requirements the senior management has for them was:

• make this feature work now
• change the behaviour of this feature (now)
• fix this bug (now, of course)

Only very few stakeholders and senior developers (hello Ľudovít Hajzer) wanted me to do this:

• write the code for this feature so other developer can read and understand it quickly
• decouple the code so it’s easier to extend it
• write tests so you can eliminate at least some bugs from appearing

But when we look at the Software Craftsmanship manifesto (that you can sign here), a set of moral standards every professional Software Developer should enforce looks different than - just write a code that works.

And yet, it’s hard to find a software developer who doesn’t consider himself a professional one. I believe, these are the reasons:

• the pressure (from stakeholders, clients, managers) to deliver quickly can be too strong and overwhelming
• the vision of an “easy life” of a software developer is too tempting (let’s be honest, there are other engineering fields where people have to learn harder than IT, but later that doesn’t necessarily translate into higher pay check)
• it’s easy to become a software developer with a whole universe of free online content and classes

So far it works. Clients are paying, software companies are signing project contracts and developers have several new job offers in their message boxes on Linked In every month. So why should we even bother about raising quality of software engineering? Especially when stakeholders are not complaining, and they cannot because they don’t understand our work - that’s why they hire us.

To answer this question, let’s ask another question:

How often does your grandmother interact with software systems?

Well, when she’s making herself a popcorn in a microwave oven, she’s interacting with software systems. When she’s executing / receiving a payment through internet banking (even elderly people can actually do that nowadays), she’s interacting with software systems.

Her, you and me probably cannot do anything without dealing with software systems for more than 60 seconds.

Another great example is cars. Software of a normal, classic car (not Tesla) consists of about 100 million lines of code. Did you know there is a code that handles breaking? That there are literally if statements between your foot and the breaks of your car? But is this code of a satisfactory quality?

We need to acknowledge that people have already died in car accidents caused by software failures. This means us, software engineers, are directly responsible for human lives!

I’m wondering, when will society realize how deeply it relies on software?

We can think of several ways as we speak. Let’s say some software failure causes an accident, that involves many human lives such as plane crash. The world leaders will afterwards rise up in a righteous anger and ask the responsible creator of that software piece: How could you let this happen?

Few years ago the Volkswagen’s cheating software scandal went public. That time answer of the CEO was, and I must quote this:

“This was a couple of software engineers who put this in for whatever reasons.”

Michael Horn, ex-CEO of Volkswagen North America

This speaks for itself. Do you think the developers really did it out of control, just on their own?

My conclusion is following: in future the world will blame us, software developers for such accidents.

With predictions like this we are on a good way to become public servants. We should better have a good answer prepared, because “it was such a pressure, my boss said we have to do this until Tuesday” is an embarrassing one and will lead to great shame and further regulations to our field. Imagine some government employee who has no clue about your work will be telling you how you should write your code. What languages to use, what books to read, what courses to do, what certificates and degrees to have…this is something we don’t want to happen.

However, if we develop some industry ethics, some moral standards, such as Software Craftsmanship (which still does not have strong position at the moment) we can be in a much better position. We could tell the government: yes, the accident happened and we regret it. But it was not due to our negligence, since we have these craftsmanship rules that we follow. So the government can take them and turn them into law. It happened to other fields (doctors, lawyers, architects) and it will happen to us as well.

This was confirmed also by Mr. James Grenning, a dedicated expert in Test Driven Development and another co-creator of Agile and Software Craftsmanship manifesto’s (and colleague of Robert Martin).

At ableneo we were lucky enough to attend an online session with James Grenning, where he spoke about Test Driven Development. I remember when at the end of the speech he said: “Lawyers are coming”.

But let’s get back to the roots: to our daily work. What do people expect from software developers?

Funny break: this is one of the popular jokes cynically describing code quality:

“Only valid measurement of a quality code is the number of ‘WTF’-s coming from behind the door where the code review is going on.”

It’s definitely straightforward measurement, but Uncle Bob would not agree. He rather has these expectations from a professional software developer:

• Zero bugs: it’s natural for everybody the code they ordered works, just like you would complain when even smallest thing in your new car was not working.
• Inexpensive Adaptability: the value of a change refers to its cost. The time to change something in the system does not rise with project age. That’s why it’s called software, because its “soft”, therefore changeable.
• Continues Improvement: because we are a group of professionals who always deliver their best work everyday.
• Fearless Competence: developers must not be afraid of changing or cleaning the code just because it could break something, they always have to be willing to get their hands dirty.
• QA / Manual Testers will find nothing: developers are the ones who guarantee quality of their code. Isn’t it nonsense to have team of developers and another team of about the same size just to cover developers backs? Loads of work can be done on developers side to eliminate the need for such secondary quality assurance.
• Test Automation: everything that can run on machines must run on machines.
• Team Work: anybody can replace anybody, there are no bottlenecks, developers cooperate.
• Honest Estimates: even under pressure, managers expect us to say NO when appropriate, so they can manage the risk. That’s why they are managers.

So what are the moral standards, the ethics in Software Craftsmanship that make a real professional?

1. Clean code

I won’t go into details, just to mention some of them:

• naming standards
• size of lines, methods, classes, files
• rules for commenting
• pair programming

2. Tests

Let’s focus on testing a bit more.

Testing is a scientific approach how to ensure the code does what we expect it to do. Why scientific? One of the definitions of any science including biology, chemistry etc. is: science is a set of hypothesis and postulates that cannot be proven true, but can be proven false so we pass them via so many tests we can be confident about claiming: yes, that works.

This is exactly what a good test suite in our software project gives us: stronger confidence especially for changing the code and shipping it. Although, we probably never achieve full confidence as well as 100% test coverage, but it should serve us as an asymptotic goal we can look up to. One of the best approaches to achieve it is Test Driven Development (TDD).

TDD means literally writing tests a priori you write code. It’s a discipline, which means part of it is artificial, just like doctors have artificial disciplines. Such as cleaning their hands before surgery.

Surgeons actually have a set of steps to follow. They divide their hands and fingers into quadrants and wash each one for 10 seconds. Quadrants and 10 are both arbitrary numbers. It should be just enough. However they’re motivated by something real…

The precise wordings of TDD rules are:

• You are not allowed to write any new production code until you have first written a test for that code that fails
• You are not allowed to write more of a test than is sufficient to fail / not compiling
• You are not allowed to write more production code than is sufficient to pass the currently failing test

Which means you ought to test code that does not exist and even make the test fail! It sounds like nonsense, what should you test then? Then you have to write a bit of code, test will pass and again write a test that fails. You have to constantly interrupt yourself. That’s tedious, slow, boring and in conflict with primary human logic. Do you already see that arbitrary aspect?

But what are the benefits of such approach?

• Confidence that everything worked a minute ago. You are just few CTRL+Z-s from the last valid state of your system.
• Documentation out of the box. Developers don’t want to read documentation, we want to read and write code and that’s exactly what a good test does: describes how part of a system works.
• It’s even more boring and complicated to write tests after you write your production code. You already know the code that was tested manually by you works. Developers also often find parts of code that are hard to test because they weren’t designed to be testable. It is tempting to skip writing the tests and therefore leads to test holes. Good test suite is like a parachute: how many holes you want to have in your parachute?

Let’s look at it from outside world. What do developers do? They produce documents full of strange, arcane symbols among which each one has to be correct otherwise it will break the thing. What are other professions that do something similar?

The accountants. They produce spreadsheets, full of numbers only they understand. Each number has to be correct or terrible things happen. How do they control themselves?

They have a discipline called Double Entry Bookkeeping. Accountants write everything twice, in both liabilities and assets side and the result after calculation has to be 0. It’s just like TDD, developers write everything twice, in tests and production code and result has to be 0 failed tests. Difference is developers (for now) don’t go to jail when they skip writing tests. Accountants unfortunately do (and here we are back at the government regulations).

Do accountants not feel pressure in their work? Do their boss yell at them to finish spreadsheets until next week so they have to skip the liabilities part?

Accountants don’t even think about it. Not because of fear of a criminal, but mostly because they are professionals. Are we lesser professionals? Is code less important than spreadsheets? Code is often primary source of income for companies, so I ask again — why don’t we use TDD all the time?

3. Clean Architecture

Since architecture is not a topic per see of this article, let me just quote Mr. Martin:

“Good architecture allows us to postpone important decisions”

Robert “Uncle Bob” C. Martin

4. Agile

Let’s refer to another short and meaningful quote:

“Only purpose of agile is to give the stakeholders the information how screwed they are”

Robert “Uncle Bob” C. Martin

We should see now various benefits Software Craftsmanship approach provides us with. Therefore I’m asking (again):

• Why don’t we enforce it more?
• Why don’t we make our lives easier using it?
• Why don’t we save our time by it?
• And why don’t we sell higher quality work and gain competitive advantage thanks to it?

On the other hand, there are also some challenges to solve:

• It’s harder to test UI, asynchronous UI changes and simulate stores in redux pattern frameworks. I can tell you a story about this since I’m Frontend Developer, working in Angular and React.
• Decide what tests are good for what. Where is the border between integration and end-to-end test? Or how and what else can be decoupled so it can be tested by unit test?
• How to properly evangelize Software Craftsmanship rules and their positive impact? I tried to speak about it to some of my coworkers. It has invoked various levels of interest, misunderstanding, disagreement and even laughter, because some people imagine a hammer and anvil when they hear the word “craft”.
• Where is the healthy level of enforcing such rules so that our work doesn’t get annoying?

As software developers, we are creative creatures by nature. We don’t want to write documentation, debug code and investigate root of the same regression bug over and over again. We want to write code, write it efficiently and quickly so we can build things quickly.

Let me conclude this article with my favorite quote from Uncle Bob:

“Only way to go fast is to go well.”

Robert “Uncle Bob” C. Martin

I hope it will stay in your head. I’m sure it will stay forever with me.

If you found anything of this interesting or want to help me with your opinion / experience with Clean Code, TDD and Software Craftsmanship, please feel free and shoot me an email at: marek.vodicka@ableneo.com

Software Craftsmanship was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why have I returned?!

I have been working with ableneo since it’s very beginning in 2017. After a year in a project, a great year that thanks to ableneo made me from complete junior developer to a professional one, I decided to bring my other passion — travelling — to the next level by moving to the Country Down Under: Australia.

Recently we had a chance for remote ‘corona’ interview between our Dominka Letkova and me about my motivations of going there and back and becoming the innovation enabler straight after the return 😊.

what was the reason you left ableneo in the first place?

It was my strong taste for exploring and my old dream: life in a completely different country than my homeland Slovakia.

Why have you chosen Australia?

Because of the weather, options for surfing and feeling of a distant, unique place since it’s a developed country in not so developed part of the world. Important factor was also the simplicity of acquiring working visa.

How long have you been living there?

14 months in total with some time spent abroad for travel breaks (New Zealand, Philippines)

What was your job there?

This was my personal goal before I even got there: to find a job as a software developer and make loads of money 😀. If I would not success in this in few weeks, I was decided to go exploring the country as a backpacker, then pack my stuff and come back home. Reality was that I was able to find the right job in two weeks after my arrival. Later I realized there’s so much work to do, so many interesting IT projects, that I changed my employer 3 times (I was always a short-term contractor) and for about half a year I was doing two jobs at once.

What is the additional value of the experience for you?

The best thing is I’ve learned how to manage my mindset and lifestyle to be able to live alone, taking care about myself and enjoying that without my parents, old friends and my previous habits. More than one year stay also opened my mind and taught me there’re no geographical borders in terms of IT business nowadays and that we can and have to sell our services to our partners and customers abroad. The salary is promising over there too, even in consideration with higher living costs it’s about double the amount software developer can earn in Slovakia 😎💰.

Name some of your best experiences you had there.

• Working in high-end skyscrapers with great Sydney skyline views
• Commuting to work on a ferry, wind in the hair, sun in the face and with views on famous Sydney Opera and Harbor Bridge
• Skiing in August in New Zealand’s Southern Alps and Australia’s Snowy Mountains
• Camping, BBQs and road trips in a camper van
• Because of the weather I could have overall whole-year outdoor lifestyle, including things you normally do indoors in Slovakia, especially in winter
• Petting kangaroo
• Vibrant, supportive and surprisingly quite big Czecho-Slovak community
• Great new international friends and colleagues
• Musical events: DJ Kygo concert, Ultra Australia festival, Sydney Symphonic Orchestra open air concert

What was the reason you started at ableneo right after you came back?

First and important reason is that my working visa has expired 😀. The second is that ableneo always was and still is something more than a job for me. In Sydney and in my previous jobs in Slovakia clients and employers wanted one thing: just to write the code and make it work now, not tomorrow or when requirements will change. I also had very little feedback on my coding abilities. This can be fine for short term projects, but I always want to build something and improve things so this is just not the way to go for too long. Very few technological companies care about quality or saving future customers resources with properly managed codebase. Also, very few consultancies and body shop companies aim to give the customer additional value, like strategical partnership, instead of just providing workforce. And lastly, I struggled to find colleagues, that are, in my opinion, better developers and professionals than me. ableneo provides me with all of this and in addition it supports me to learn something beyond my expertise, such as sales, leadership and brand ambassadorship 😊

What do you do at ableneo at the moment?

I am Software Engineer with focus on Frontend technologies Angular and React. ableneo and me also voluntarily invest our time to my education in sales through our Sales Academy, sales pitching and presentation through our Brand Ambassador Academy and leadership thanks to the chance I can organize workshops for internal ableneo Frontend developers stream.

Since when are you with us again?

Started again just one week after I came from Australia, which was 2nd September 2019 😊. That makes it 9 months now, a time slot long enough for a new baby to be born 😛. I don’t mean anything concrete. 😀

Are you satisfied at ableneo now or are you looking forward moving to Australia again?

So far, I feel super great at ableneo. However, Australia became my second home, it matches with my lifestyle preferences and it would be great to regularly spend few months in a year there. The problem is the visa: man can get the one I had once per lifetime only and it’s either harder to get different ones or less convenient to live and work with others. One way I can imagine to make this happen is to find Australian clients, apply for Business Visa and establish local ableneo Australia branch in Sydney 😛.

From ableneo to Sydney and back was originally published in ableneo People on Medium, where people are continuing the conversation by highlighting and responding to this story.