When business does indeed sucks

In a recent article I explained why I think we should all be Domain Driven.
I get some interesting feedbacks on the “business sucks” syndrome.

Indeed in this previous article my point was to make technical teams aware of the necessity for business to change in order to constantly fit its market as much as possible. But sometimes business does indeed suck.
Let’s take a few examples I’ve met in 10 years as a software developer.

The never-ending prototype

One of the most common business error I’ve met is the fast hacked prototype that goes into production, and then evolve in a maintenance nightmare because you know… It works, why should we rewrite it?
To be fair, this is one of the hardest things to do when you start a new business. The first step is to look for a market fit. This can take years, and you must be very fast to test your hypotheses. You are sending many prototypes in production, and most of them will only live for a few months. At this step this is perfectly fine.
Of course the problem arises when, finally, you find your market fit. The growth is here, more and more customers are using the prototype. This is when courageous entrepreneurs should throw all the technical stuff, and write it from scratch with more money and knowledge. More money because growth means that we can get money, more knowledge because many technical limitation from the prototype will be clear, and a more robust product can be built from this knowledge. As Francesco Cesarini would say: “A programmer will fully understand a problem only when he fixed it at least once”.
What happens instead is that the money is used to growth even faster, the prototype has to scale even if it’s not done for it, and the technical team has to deal with many domain and technical problems that should have been avoided.
Here starts the famous “we don’t have time for tests, we have to deliver”.

Head in the sand policy

This error concerns mainly big corporation. But I’m sure you already were as surprise as me to see how fast politic can become important even in small companies.
The company is big enough to have a few layers of management and different services. Because the top managements want to keep control of the company, he’s requesting the famous KPIs. Each service has different KPI, and quickly enough, most employees understand that they can earn more money by targeting the KPIs than by trying to achieve the best possible product for their customers.
Worse, KPIs might be highly destructive when the KPI from a service leads to more burden for another service.
For example, if one of the KPI for the support team is to take as many call as possible, they will quickly classify lots of tickets as critical bugs to be managed by the technical team. Just because it’s faster than trying to understand what happens to the user.
As a result the technical team might have a more work and the global delivering flow of the company will be slower.
Each service prefer to keep their head in the sand rather than trying to collaborate with other ones.

Enterprise Standards

Another widely spread error is the standardisation spree. Usually in the name of costs hunting (even if it’s more about power and control, because in the end it often cost more than local auto organization), the company imposes some methods, tools and/or architectures, without knowing if it makes sense for a given context.
For instance a policy will enforce all the teams to work with SCRUM. Or they will impose a common integration platform for the whole company.
It often happens when management confuses practices (SCRUM, Unit tests, continuous integration…) with principles (being more agile, code quality, fast feedback…).
Many consultants actually increase this confusion and deliver what they (think to) know instead of what the company need in its context.

So should we be domain driven when they suck?

I think my point in the original article is still valid. In the end the problems I described here is just that sometimes, the business itself is not Domain Driven. In the sense that they are looking for immediate profit or power and control instead of caring about the domain.
Thus we should all be Domain Driven, especially the business part of the company. And writing it like that is a bit depressing, but yeah, quite often the business part of the company does not really care about the domain itself.
In this case, we should help them to be more Domain Driven, or just leave them and go work in more healthy environment 😊

 

Dry should not be technical

Do you know the “I talk about it so often that I believe I already wrote a blog post about it” effect? It happens when you talk about something so often that you are sure to have a blog post somewhere to explain it more deeply 😉
It happens to me recently about DRY (Don’t Repeat Yourself). In a twitter conversation where I once more had to explain why DRY should not be technical. I’ve looked for my blog post about it. Just to find that it doesn’t exist yet… Thus, here it is.

DRY ?

According to Wikipedia, DRY is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.
One of the main arguments for avoiding redundancy is to improve software maintenance. It seems great right? If you have to modify the code in two places instead of one when you want to change a behavior, you increase the risk of error.

Coupling ?

According to Wikipedia, coupling is a measure of how closely connected two routines or modules are.
Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.

The main issue with DRY when apply dumbly is that it increases coupling (which is a code bad smell). Because, sharing the same code between two things create a coupling between them. Too many developers consider that two identic lines of code in the system must be merged and shared into one, because we want to be DRY.
The key to have a smart refactoring in order to be DRY is to care about cohesion.

Cohesion ?

According to Wikipedia, cohesion refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class’s methods and data themselves.

If we share code between two modules with low cohesion, the result is a dramatic decrease in maintainability. We take the risk to break the second module, each time we want to change something in this shared code for the first module.

DRY Should not be technical

An easy way to avoid this pitfall is to consider the business concept of what you want to share.
If the business concept is the same for the two modules, you can share it with less risks, because it should evolve for the same reason in the two places.
If it’s just a technical concept, sharing it may be dangerous, because both modules will probably need different updates depending on their use cases.

Of course it happens because, no matter if you know/want it, you’re Domain Driven. It means that your module will evolve because of business requirements. Low cohesion means the two modules have different business purposes, then will evolve very differently. And we don’t want to share something between two things that evolve very differently.

Let me recap

  • To be efficient, DRY must be combined with high cohesion (and few people remember that)
  • An easy way to detect cohesion is to care about the business goal of each module

I do believe it’s one of the first good practice easy to apply that can radically change your code maintainability day after day.

 

We’re all Domain Driven

Believe it nor not, one of the main reasons why software exists is to help companies to make money. These companies earn money because they have a business. Usually they sell something to customers, in order to solve a problem for them.

A software developer that doesn’t care about the business is missing an important point. It creates a mismatch between the business and the software. This mismatch makes the system harder to maintain, because even if we don’t want it, we’re all domain driven.

The burden to maintain this system lies on the IT team. In other words, denying the domain aspects of the software is a way to shoot yourself in the foot.

How to recognize this mismatch

When this mismatch happens, there are many patterns that emerge.

One of them is the “business sucks” syndrome. You can recognize it when the IT team is always complaining with arguments like “they don’t know what they want!”, or “they always change their mind”, and even “they sell something that doesn’t exist!”.

Of course they sell something that doesn’t exist, otherwise how would you know what to build?
Of course they change their mind, because they are constantly testing and adapting to customers.
Of course they don’t know what they want, precisely because it doesn’t exist yet, and it’s not trivial to know what’s possible to do with software.

Let me raise a warning though, selling something that doesn’t exist is totally legitimate from a business perspective. But stressing someone else because a business man took unrealistic commitment with a customer is not.

It’s the business job to sell stuff that doesn’t exist, and then to handle customers expectations until it’s delivered. It shows why it’s a team work. Without the production team, the business man has only dreams to sell. Without a business man, a production team has no one to sell the product. The sweet spot is to sell something that doesn’t exist, but that can be done quickly. In other words, something that “almost exist”.

How to handle this mismatch

The solution is to let the business drive your software. To let your domain drive your design. Good news, there is a bunch of literature about Domain Driven Design!

It can be resumed by: organize your code, then your teams, then your company around the business, and you will improve software maintainability and customer satisfaction.

It seems trivial, but it isn’t. Trying to know at every line of code which business purpose it serves is hard. Trying to know at every meeting which business purpose it serves is hard. Trying to know if the company has a structure that serves the business is hard.

It’s even harder because as the business evolve, the whole structure (company, teams, software) should evolve as well.

To be fair it’s so hard that I don’t think any company can achieve it. But trying to constantly improve following the principles of Domain Driven Design is good enough to be far better than the average.

 

The Road Less Traveled

“Confronting and solving problems is a painful process which most of us attempt to avoid. And the very avoidance results in greater pain and inability to grow both mentally and spiritually”. Does it remember you something? Root cause analysis, Domain Driven Design and so many practices in IT are about solving the problems instead of fixing the consequences. Actually, I think it’s the difference between a young and an experienced developer. The young dev wants to hack a solution as fast as possible. The experienced dev will use this time to analyze the problem, because when it is done correctly, building the solution will be “trivial”.
The passionate thing about The Road Less Traveled by Scott Peck is that it’s a book written by a passionate psychiatrist, drawing heavily on his own professional experience. It’s all about human relationships, and the incredible number of lessons from this book we can directly apply in our software developer job should be a huge warning for people arguing that we must be technical monkey.

Discipline

Seems familiar again? That’s the very first section of his book. Through different experiences he explained how discipline is important to grow as an adult, and how most of us stay children. Each time we refuse responsibilities, each time we look for the easy solution instead of a more permanent one, each time we take a direct gratification instead of investing in a delayed but greater one, we are acting like children. This book brings us this hard truth: being an adult is not fun, and nobody will help or prepare you to become one. But fleeing our responsibility results in pain. That’s why discipline is required to grow as an adult, even if it hurts.

Love

This one is a bit far away from software development, but important for mind growing. In a nutshell, the author tries to define love: true genuine love. Not the one you think to know when you’re 16 years old and discover the opposite sex. True genuine love is the unconditional love we have for our children for instance. This kind of love does not require anything from the loved one, it does not have to be mutual. It’s just something you give to someone. This kind of love is hard, and usually not what we’re used dealing with. It excludes the myth of “love at first sight”, because genuine love requires a deep understanding and respect of the loved one. The author explains that this kind of love is the one that can stand for life.

Religion and Grace?

The two other sections use some words that make me very careful… Religion, Grace… I believed this psychiatrist was a scientific man? But the reading was still really pleasant. The author is not trying to convince you of anything (even if he personally believed in god, or at least in something bigger than us). Again, he drew on his experience to relate some stories were religion drive people crazy. And some stories were these same religions literally save people. And grace is about all these things that we observe but can’t explain. What’s the link with psychiatry and psychology? Well, to be happy you need to accept that you won’t understand the world.

Yet another must read

It will not be the book that will make you a better developer technically. But we can feel the passion of the author through chapters, and his feedback on human relationships are priceless. It helps me to realize how much the job of a software developer is driven by people’s relationships, more than by anything else.

I highly recommend it.

 

I did often fail

I like to read technical blogs. I do it daily since a few years now, and I really enjoy the way in which this community is sharing in order to improve. I would argue that it’s an efficient way to raise the bar of the software industry. There is one thing I regret though: we almost never talk about our failures. We talk about concepts, implementations, and how we think the industry can be better. But we very rarely share about our failures. I do meet failure more often than success. I think it’s a good idea to share about it, because people who read us without working with us may think that we are kind of “super developers”. We are not. Let’s talk about how we fail and why.

When the pressure comes back

I’m bad to work under pressure. I mean like really bad. My brain is just in panic mode and seems to hide data from myself when I’m stressed. I can physically feel the pain when I try to focus in this situation.I have no way to clear out my ideas, my mind goes in many directions and I almost systematically miss obvious stuff. The usual result is that I push code I should never have committed (like code I changed “just for test”), and/or that I need lots of time to sort out simple problems. In this situation, I may bypass some quality practices because you know… We’re in a hurry!

Where does this pressure comes from?

In ten years, I learned to say no, thus it generally does not come from other people. It’s usually my own commitment due to my own estimation. And in ten years I learned to be very careful about my estimation.I know that unexpected things happened all the time. And still, the pattern is almost always the same. First I commit to a deadline that seems correct to me.Then I’m not as fast as expected, and I feel like I lose time on trivial stuff.Finally, I feel guilty that it takes “so long” for this “trivial” thing. I feel like it’s “almost done” and work extra hours in order to finish it. I see the pressure growing. At some point, I bypass some quality practices (no one is here to validate my pull request after 8 pm anyway… And do I really need this test? This piece of code seems so simple…)

Consequences

The consequences are most often the same. The few hours of extra work cost me a few hours/days to fix it. My colleagues usually look at the PR in the morning, and it took them a few minutes to spot my mistakes. That was the cost of my extra work. That is how productive I am when I work 10 hours a day.

A developer with good practices

It reminds me this truth from Kent Beck I know for a while: I’m not a great developer, I’m a developer with great habits. Losing these habits make me much less efficient. And even after 10 years as a software developer, it’s still easy for me to discard these practices.

Being a code crafter is a continuous challenge.

 

Migrating Database from ClearDB to MySQL for WordPress in Azure

You know this feeling when something that should take an hour finally take a day? That’s what happens to me when I tried to move my database from ClearDb (because it’s no longer included in the MSDN subscription). I wanted to use the free MySQL in App instance instead, and I wasn’t able to find a simple and complete guide for that. Hopefully this one will avoid some pain to some people.

About ClearDb and MySQL in App

ClearDb is a Saas service for MySql database. They used to host the WordPress azure app service. But now we have to pay for it as it’s no longer included in the MSDN subscription. An alternative is to use the free MySQL in App database provides by azure with app services. Beware that this Database is normally for testing purpose, they are not recommended for production. But for a WordPress site hosting a blog like mine, I think we should be fine.

Let’s save everything

The first action to do is to save your website (Just in case :)):
YourApp -> Settings -> Backup

The second action to do is to save your Data from ClearDb. The easiest way I found was to activate MySQL In App:
YourApp -> Settings -> MySQL In App

Click on “activate”. Then you would be able to click on “manage” in the upper left corner. It will open your php MyAdmin UI for your web app. You normally have (at least) two server available in the server list in the upper left corner. One is for your ClearDb database, the other one is for the localDb from your MySql In App.

You can select the ClearDb server, select your WordPress database, and use the export button to get a sql script from your DB schema and Data.
Now you can select the MySQL In App server (localhost), and use the existing localDb, then import the sql script that you get from the ClearDb database.

Reroute WordPress to the new Database

Last but not least, you need to change the wp-config file from the WordPress site to use the new MySqlApp database.
Go to https://[yourwebsite].scm.azurewebsites.net/ to see your Kudu UI. Using the Debug console, you will find your wp-config file in: D:\home\site\wwwroot.
You need to change the following values:

define('DB_NAME', ‘localdb’);
define('DB_USER', ‘azure’);
define('DB_PASSWORD', 'password’);
define('DB_HOST', ‘127.0.0.1:port’);

To know the value for the connection you can check the ConnectionString for the My SQL App in D:\home\data\mysql\MYSQLCONNSTR_localdb.txt
It should looks like this:
Database=localdb;Data Source=127.0.0.1:port;User Id=azure;Password=password
Just extract your database name, user id, data source (host) and password.
Note that you need to precise the port for the host.

Cleanup

You can now remove the ClearDb connection string from the app service:
Settings -> application settings, connection strings
And of course stop your potential ClearDb subscription!

Hope it helps.

 

 

 

 

 

 

 

How do you teach DDD?

The more I work using Domain Driven Design in my daily job, the more I face how hard it is to teach. What’s the matter here? Why is DDD so often misunderstood? Of course, we can just consider that it’s a complex thing, hence requiring lots of knowledge and practices to be mastered. But let’s be more constructive and try to find the root problem in the domain of DDD teaching.

Like always, we need to agree on the terms we’ll use through this post.

Reminder: DDD

DDD is about tackling the complexity of the domain in the heart of software. It means that, in an ideal world, your software must be as complex as the problem it’s solving. Plus, the problem you solve must be the most valuable possible thing for your company. DDD provides patterns to address these points (spoiler alert: it’s not an easy task). Implementing DDD is all about analyzing dependencies.

Reminder: Tactical patterns

Tactical patterns are the most concrete parts for us developers because it’s about code! It’s a set of technical tools to concretely apply a DDD approach where it matters the most. These patterns evolve quickly, at the same speed as good practices. A well-known example is the repository pattern. Tactical patterns help to know how to build each part of a business.

 

Reminder: Strategic patterns

Strategic patterns are more abstract. They allow to categorize the domain (the business) into subdomains, in order to know how to build context of applications around it. Each context has a specific common business language (the ubiquitous language) and use precise way to communicate. Does a context impose things to another context? Do they share a kernel? How do they communicate? All of this can be captured using strategic patterns. They help to know what the different parts of the business are, and how they interact.

 

The DDD usual problems

Since I start studying DDD in 2012, I meet two recurrent problems.
The first is that newcomers (including me) do not know where to start. They can feel DDD is huge, but the reference books are intimidating. The community of smart peoples using words you never heard before seems nice, but you feel so stupid around them that it’s hard to stay.
The second one is that most people (yep, was me again) will not grab the duality of strategic versus tactical patterns at first glance. Worse, they may stay focus on the tactical patterns because they seem more concrete. We already know some of them, like factories or layered architecture. The consequence could be that we overlook the strategic patterns.

Root cause analysis

Following the principles of good design, how can we improve DDD so that these mistakes are harder to make for newcomers? Let’s use my (almost) secret silver bullet for that.
In my domain of DDD teaching, I believe there are two sub domains: one is about tactics, the other is about strategies.
An efficient implementation for teaching DDD would map one bounded context for strategic patterns, and one context to for tactical patterns. We have several clues to justify this implementation.
First clue: different languages. The two contexts have specific ubiquitous language.
Second clue: different life cycle. Tactical patterns evolve quickly. Most of the patterns from the blue book can be replaced by more recent patterns like CQRS/ES or hexagonal architecture. Strategic patterns are much more durable.
Third clue: the level of abstraction is not the same in both contexts.
Last clue: the strategic context is much more important. It’s my core domain, the core values I want to share when teaching DDD. There is a clear dependence between my contexts. Tactical patterns are important but will bring much less value if I teach them alone.
I now have a part of the answer about why DDD is hard to teach: it mixes two very different contexts. Both are useful, one is more central than the other, but also more abstract, hence harder to understand.

Solution attempt

Eric was really ambitious in his attempt to improve the industry, providing both strategic and tactical views. I think the trending and the emergence of major DDD conferences across the world are proofs that he succeeds. I also understand his willing to provide something that is not only abstract, to avoid the architect ivory tower syndrome.
Still, strategic and tactical patterns are really different beasts. These two faces of DDD make it harder to understand.
How can we manage this complexity? It depends on the context (did you see that coming?). But in the domain of teaching DDD for newcomers, I would accentuate on strategic patterns, mainly bounded context, because this is the pattern that can lead to all other patterns. Then I would explain that all the industry standards good practices (continuous integration, segregation of responsibility and so on…) are mandatory to implement the core domain, and that DDD also includes them under the name tactical patterns.
Trying to go the other way around (teaching the tactical part as introduction to DDD) increases the risk of missing the core concepts.

As always, it’s not a recipe, but it may be a way to facilitate the understanding of DDD.

 

The context of OOP and FP

If you want lots of reaction when you tweet, a sure recipe is to talk about Object Oriented Programming (OOP) vs Functional Programming (FP).

Let’s throw the cat among the pigeons, with another blog post on the Internet giving personal perspective on OOP vs FP. I’m far from being a functional expert. I code professionally mainly in C#, and sometimes in F#. I only play with Haskell and Idris in coding dojo. I’m not trying to convince anyone about anything. I just would like to share my thoughts about these two important paradigms.

And the first step would be to agree on what’s OOP and what’s FP.

What’s OOP?

To really grasp the philosophy, I highly encourage you to follow Alan Kay’s work. Of course, he’s not the only one behind this paradigm, but I find his explanations really clear. This keynote is a good start. In a nutshell, Alan has (beyond other knowledge) a PHD in biology. The way complex organisms are working is basically what inspired the OOP paradigm. In other words: collaboration through specialize components to achieve a complex task. Each component can be independent and don’t need to be aware of the full system. They just collaborate, receiving some messages when something was required from them, and sending messages when they have done something meaningful for the system. How these components communicate, and how the orchestration between them is managed is not imposed by the paradigm. And different languages have used different implementation. But this notion of independent component collaboration is the core concept of OOP. Not really what we see when we type OOP in duckduckgo…

What’s FP


Instead of looking for inspiration in the biological field, Functional Programming is rooted in mathematics. I’ll quote Philip Wadler to give a better definition:
A program in a pure functional language is written as a set of equations. Explicit data flow ensures that the value of an expression depends only on its free variables. Hence substitution of equals for equals is always valid, making such programs especially easy to reason about. […] Explicit data flow also ensures that the order of computation is irrelevant, making [functional] programs susceptible to lazy evaluation.”
What does he means? If I write X = A+B, or Y = C * D I don’t care about the values of A and B, or C and D. That’s a mathematical equation, it represents the concept of all the valid values for an addition of type A and B, or a multiplication of type C and D. Hence I can compose X with Y, and do substitution:
X>>Y = (A + B) >>  Y = X >>( C * D) = (A + B) >>( C * D)
(>> is the composition operator in F#)
If any of these values have the possibility to change (mutate) outside of my scope, all this reasoning is no longer true. Even worse if not only the values, but also the types can change. That’s why we say that in FP, we can write code only thinking locally. I know that my “equations” (or pure functions) are always true, no need to think about the rest of the world to ensure that.
Please note that this willing of “local thinking” can also be find in the “independent components” from OOP. But contrary to OOP, FP explains how it can be achieved, thanks to mathematics.

Which one is the best?

Finally, the answer the whole industry was looking for since many years. Here it is: none of them, because this is not the good question. The question should be: which one is the best in my context? And now we can start to talk. I think the answer is easier that what many believe.
The more constraints you have, the harder it is to write code that woks, the easier it is to maintain the code in the long term. What are code constraints? We have many of them depending on the language: syntax, immutability, no side effects, unit tests, types and dependent types for example. Is it better to write code faster or to have long term maintainable code? In a start-up context, I probably need to produce code quickly, until I find the good product. In a critical context where lives are involved, I probably want something robust, even if I need 1 year to write it. And of course, there are all the scales from “quick and dirty” to “mathematically robust” that might be your context.

Just tools

Functional Programming is by nature more constrained than Object Oriented Programming. Because it forbids mutability and side effects. When the language also uses types, it leads to powerful concept like Type Driven Development where we can, by design, remove the invalid states from our system, to make it more robust at runtime. And when the language also uses dependent types, we can even encode business rules into the types, to avoid compilation if a business rule is not met. As a drawback, it is harder to write. But when you achieve to write it, you can trust the famous quote “if it compiles, it works”. Maintaining this code is usually easier than a huge OO codebase, because thanks to pure functions we can use local reasoning to maintain the system. Please note the “usually” in my previous sentence. A “good” OO codebase can in theory have this property of local thinking, but the fact that side effects and global impact are not forbidden by design makes it almost impossible to scale (at least in my experience).

FP is hard to write, but easy to maintain (easier to reason about). OOP is easier to write, but harder to maintain (harder to reason about due to side effect).

 

 

 

Remote

This book is the second-best seller by Jason Fried and David Heinemeier Hansson. I’ve already commented the first one. It was basically one of the most pleasant reading experience I had so far, in terms of presentation. Knowing that they have written a book about remote working, I had it in my reading list since a while. As a remote worker myself, I was sure to learn stuff, or at least to discover another pleasant book to read.

William Zinsser’s touch

Like for Rework, we feel the hard work in this book to write only essential things, in the most comprehensive way. From the writing style to the chapters patterns and the images to illustrate them, we feel that nothing was chosen by coincidence.
The result is again a delightful experience.

Content

Thanks to this writing style, clear and concise, the chapters follow each other with lots of takeaways. Short and actionable things you can do tomorrow, either as an employee or as a company, if you want to use and promote remote working.
There are also many arguments about why remote working makes sense, from a human and economical perspective. Including counter arguments to explain the challenges that arise with remote working.

Favourites takeaways

– You can work remotely just a few days per week, or even per month, it doesn’t need to be all or nothing
– Just staying in front of a computer is not working, the work is what matters wherever you are
– A demotivated remote employee is also demotivated on site
– On site or at home, we need a routine to perform
– It’s all about trust in the end

Should you read it?

If you are a remote worker or a company working with remote workers, this book will definitely be helpful. This is also true if you are interested by remote working, but don’t know where to start.
If you want to learn how to write a book which is a pleasure to read, this is a must read as well.

Have a good read!

 

Breaking people

An interesting discussion including  Yannick Grenzinger, Romeu Moura and Daniel Gonçalves has recently happened on Twitter. Thanks mates for the respectful and enlightening exchange.

It started from this:

The first objection was from Yannick Grenzinger:

Which, as  Daniel Gonçalves noticed, resonates a lot with an older tweet from Nicole Rauch:

I think the matter deserves a blog post to explain my position. Not because it’s the right position, but rather because we all have different experiences, with interesting things to share. I kind of agree with Nicole, and still I think we can survive it, if we stop trying to fix the system.

What’s breaking people?

The first step is to agree on what it means to “break people”. I was once, when I started my career.
We feel broken when we lost interest in what we are doing. When we stop trying to improve, because it seems excessively hard. We know that something better could be done. But we feel that whatever we can do will not have any meaningful impact. First, we lost our motivation, then our discipline, and finally our values.
Because what we can do doesn’t matter, it doesn’t matter either way if we don’t write a unit test for this code, or if we don’t take the time to refactor it. It doesn’t matter if the build is broken or if there isn’t any automatic build. It doesn’t matter if we ship bad software for unhappy users. That’s because of the corporation, not because of us. They want us to ship too fast. They want us to write crappy code. They recruit only juniors. They don’t care about code quality and good software. They don’t want to hear about pair programming. They just consider the IT as a cost centre. If they don’t want to change and see the world like us, there’s nothing we can do.

The global local impact

I’m a firm believer that you don’t change the world by imposing your view. You change the world by acting locally and leading by example. That’s exactly how I understand Gandhi’s mantra “You must be the change you want to see in the world”.
When I do consulting for a company, no matter how big it is, I start by acting locally. Of course, it would be easier to act globally. It would be easier if the whole company, at all levels, will follow the agile principles at once. But it never happens to me. And who am I to know the correct way of working for the whole company? I don’t know. What I know is how to write software efficiently. What I know is that it doesn’t belong to any managers to choose if we must write unit tests, or if we should use a build server and do code reviews.
Whatever the context is, I can keep my discipline and my values, which are mandatories to stay motivated.

But the system will break you!

Fair enough, that could happen, but at one condition. Only if I fail to recognize the moment when the “system” is creeping into my local safe area. I did this mistake once, and it won’t happen again.
Since then, when I do recognize this moment, I do whatever is possible to protect the safe area. The last possible solution is to abandon it and let it collapse.
Is it a big deal? Absolutely not. Our team could fail, our product could be shitty in the end, our company could re-create a command and control culture, but I (and the people convinced by my example) will be safe. Because we will leave and find another place where the culture is less corrupted, where it will be possible to manage a full project, at least locally, with our discipline and values.

So you’re just a coward?

I always clearly explain how I work during interviews. My behaviour will never be a surprise, as I clearly state that some practices are not optional for me to work.
Anybody who has already quit a gig or a job know how hard it is. Like every other passionate people, I have strong feelings about my job. And it takes lots of courage to admit that we’re no longer in the capacity to protect our local safe zone. It’s a failure. It is the proof that we couldn’t change enough people around us. But it doesn’t mean that we must abandon our discipline and values. It just means that we must abandon this toxic context, to find a better one.

How do you change anything if you left when it’s hard?

As it happens, lots of companies are looking hard for competent developers, with strong skills, discipline and values. It explains why, in 10 years of professional software development, I only need once to quit such a toxic environment. Since, I’ve always found some places where my discipline and values are much welcome.
I didn’t change any system so far, but I’ve done more important things. I’ve influenced the way of working of several people, in such a way that broken systems were no longer able to break them.

Changing things is not as important as changing people. From the latter, the first will happen.

 

 

 
IP Blocking Protection is enabled by IP Address Blocker from LionScripts.com.