3 bad coding habits of most software developers

And trust me, when I say “most developers” I include myself as I am now, or as I was a few years ago. 
Let’s talks together about the most productivity killer habits most of us share. I’ll discuss them from the less to the most common with my current experience. 

2 hours of manual testing can save 2 minutes of automated testing 

Unit testing is more and more widespread, but of course the game now is to explain why, in your team/context, you “can’t really do this”. 
A few of the usual excuses we tell others (and ourselves) are: 
– This is just a little project 
– The team is not trained/ready for this 
– We do not have time to write tests because we need to deliver features 
– Unit tests are worthless, we prefer end to end tests 
But 2 hours of manual testing can save 2 minutes of automated testing. Unless you won’t need to test your feature more than once or twice, writing an automated unit test will most of the time worth it (especially if you write it before, hence keep a testable architecture) .
Honestly, what would your customers say if you tell them that you don’t test everything at each release? Or worst, that most of the cost of the development process is actually manual testing of the software? 
Trust me I fought this idea long enough and was looking for many alternatives. As many beginners, my first contact with this method was something like “why the hell would you ever need this if you know how to code?” 
But in 10 years, I still haven’t found anything better than unit testing to deliver quality software and to speed up feature delivery in the mid and long term. 

2 days of Pull Request can save 2 hours of pair programming

I know the first point about unit testing is probably consensual enough, at least by the reader of this blog. And I know that this point about Pull Request will trigger much more discussion. 
My point is that, most of the time, Pull Request is a (bad) way to implement collaboration in the team. Probably one of the worst way to do it because: 
– It is asynchronous and necessitates lots of context switching both for the author and the validators 
– It slows done the flow of feature delivery as a Pull Request can stay for days in the review stage 
– It implies a relationship where the validator judge the job of someone else, and often feel necessary to add comments just to show that she took the time to seriously read the Pull Request (and sometimes it’s a true hierarchy relationship, when only architects or tech leads are authorized to validate Pull Requests) 
Yes, 2 days of Pull Request review can save you 2 hours of pair programming. Plus pair programming will improve the common code ownership, spread good habits, coding tips and domain knowledge in your team much faster. 
Should we avoid Pull Request then? No but use it only when it is strictly impossible to do the work directly in pair or mob. I hear you: “But my manager will kill me, 2 people to do the same tasks is pure madness!”. 
A first step to feel the benefits of what I describe here is to ask for synchronous reviews with the author. It will be much faster to validate it, because it’s easier to understand what our coworker means with her voice than with her code only.

2 weeks of coding can save 2 days of Event Storming

If I had only one thing to tell to younger me, that would be “Not Silverlight!”. More seriously that would be “being able to quickly understand any domain context and the human relationship involved in them will make you a much better developer than mastering any of the shiny tools around”. 
Don’t misinterpret me, methods and technology matters, but the challenge is to find the one fitting your context. Whereas most of the time we just impose our technical knowledge (ie habits) to the business (which is why most software are just CRUD built on relational database with the last fancy framework if you ask me). 
The thing is, we don’t care how good domain experts and/or the company are. The most critical point in software development is how well the developer will understand the domain. 
The best method I know so far to share business knowledge is known as Event Storming. It’s basically a meeting between technical people and domain expert to talk about how the company earns money. 
I know, business people are “really busy” and it’s very hard to get them for a few hours talking with you. The question though is, can they afford throwing away weeks of coding (or worse: keeping bad code and trying to fix it for the life of the software), when people will realize that the software doesn’t fit their needs? A few days of Event Storming, even with the whole team, is really cheap compared to the usage and maintenance of a bad software. And like for pair programming, it improves the feeling of common ownership of the software, more people feel involved in the process of creating the right tool for the company. 

Why are these methods still unusual? 

First of all, I would say that they are more and more common, but of course it’s still far from the usual way of working. I think it’s mainly due to the following points.

Line of business software are so complicated that nobody can control them. A corollary is that this level of complexity should be managed by a team, with proper tools. But we usually ignore this fact, due to our ego or just by habit.
All these methods have midterm return on investment, and are thus hard to evaluate. It doesn’t fit well in a company with a Taylorist state of mind and management, which is still the majority.

But as soon as you accept the complexity of software development and keep an egoless approach, these methods suddenly seem absolutely normal, as a way to avoid time wasting. 

 

Event Storming and Event Modeling from the trenches

In 2014 I had the chance to join a workshop on Event Storming by Alberto Brandolini at BuildStuff. After that I started to practice it intensively at work and was quickly convinced that it was a very interesting asset to do my job. Indeed, as a consultant I meet many teams, and need to understand in a few hours as much context as possible. It is surprising how, with the right tool, you can even learn things about the job that business experts themselves were missing because they lack time to think about it. 
In 2019, I added another string to my bow thanks to a workshop on Event Modeling by Adam Dymitruk and Greg Young in Lyon. As already explained, it covers some lacking for me in the Event Storming approach, and thus I find it to be a very complementary method to Event Storming. The synergy of both tools can be huge.
I would like to share with you how they help me to improve my craft, plus give you some tricks from the trenches. 

Event Storming from the trenches 

A quick lesson I learned from early Event Storming is that all Event Storming are different, and this is great. Of course, they are different in terms of content, but what I mean is that they can also be really different in form. Because they will always adapt to your context!
For instance, it is sometimes enough to put only the events (no commands, aggregates or even contexts), because it will trigger the necessary discussion, and you won’t need to go further.   

An important point is to agree before the Event Storming on why you are doing it. You want to cover a new feature? You want to explain the business to someone else? You want to clarify a point with your team? Depending on the end goal, the form should be adapted to suit your needs. 

By experience, the law of two feet works very well for an Event Storming workshop. You don’t want people to be disengaged, and you don’t need to have all the team all the time. Some might take a break while others are digging a specific point, and this is great. Collective intelligence at work! 

In terms of timing, I believe that half a day is basically the most that you can do if people are really invested. It can be exhausting to carry such a workshop for too long. Keep an eye on how people feel and don’t hesitate to call for a break if you feel like the mob need it. 
 
Something I rarely see when people talk about the Event Storming session they performed is drawing a link between events and commands between contexts, when an event in a context triggers a command in another one. It gives you an instant view of Bounded Contexts relationship, hence some hints to know if your contexts are well defined. 

Finally, after many attempts, I must say that for me, Event Storming is a killer tool to have a big picture view of a situation. I’ve seen it a bit less valuable when I needed to dig in the implementation on a specific part (in the solution space if you prefer). This is where Event Modeling came to the rescue! 

Event Modeling from the trenches 

One of the main feedback I had from my many Event Storming workshops is that losing the temporal link between the events was a shame, because it has a great value to describe business workflow. For me this is one of the main benefits of Event Modeling. 
It makes it very good to explore concrete implementation, to represent business workflow and to link it with the UI.  
 
And like Event Storming, it gives a very good domain view, especially when combine with Event Sourcing and CQRS. It is powerful to describe the solution workflow, as you imagine and then implement it. 
With time, as the model evolve and grows in maturity, it’s something really valuable to support technical and/or business discussion. 
As Adam would say, this is sort of a blueprint of the system that a business or a technical profile can understand easily. 

I find useful to take screenshots of such models to add into User Story as documentation, or even in Pull Request in order to describe which part of the system we updated (showing a picture before the Pull Request and after the Pull Request for instance).  

Another trick to reach an interesting model is to describe each workflow separately, even if we feel that some of them will be handled by the same piece of code. Then when all scenarios are well described as a unit, you can try to merge them into a single one that could theoretically handle all of them. But even there it’s interesting to keep a trace of all the single scenario that leads you to this design. 

Hope it helps! 

I hope these few tricks will help you to perform better Event Storming and Modeling sessions. I could add that whatever the workshop you do, capturing the end result in a Miro board (or equivalent tool) is usually a good idea for asynchronous communication and future evolution of the model.
But if you should keep only one thing from this article, it would be don’t worry too much about the form, keep whatever works well as an event driven description for your team, and don’t mind how you call it.  
 
Because domain events are the powerful idea here, Event Storming or Modeling are “just” a way to exploit it 🙂