Don’t reinvent the wheel

In all advices we receive as software programmer, one of the most misunderstood (just after don’t repeat yourself) is don’t reinvent the wheel.
Of course, it seems pretty obvious that if we re-do everything all the time, the whole industry won’t evolve at all. But when we dig enough, it is clear that all of us do not have the same definition of a wheel.
I would like to explain here that defining what needs to be re-do in your context might be harder than it seems.

How we made The Usual Suspects | Bryan Singer | The Guardian

The usual suspects

I often hear this argument for 2 main software parts: some User Interface (UI) component and the Object Relational Mapper (ORM).
For the UI this is usually used for complex grid with advanced features like filtering or advanced search for instance.
The ORM is this magic piece of code that let you manipulate data in a database without even think about it.
In both cases it seems perfectly reasonable to suppose that it will accelerate your development workflow to use them. Because after all your job is not to fetch data from a database or even to display them in a nice filtrable grid.

Small Business Success Stories - Company Bug

The success stories

I do not have any scientific data to demonstrate what will follow, and I admit gladly this is just gut feeling. I’m ready to bet though that many of you may have done the same experience.
You use the awesome UI component, and you’re able to deliver in production pretty fast. You can impress the stack holders during the demo thanks to many features in the UI. Most of them won’t be used but you know, who can do more can do less!
The story with your ORM is quite close, everything is working and you didn’t write a single line of SQL. Database migration is automatically handled and you don’t need to know how it works. How glorious is that?
This is by the way where most tutorials stop you’ll have to discover the rest by yourself.

Quantum speed limit may put brakes on quantum computers

The limit of the approach

One morning a user calls you: “I don’t understand why it’s so slow since the last update?”
The problem is that you don’t know either, worse it’s not that bad on your machine. A few logs and search later, you nailed it, one of the queries tries to fetch 80% of the database just because someone in the code try to get some unrelated data in a weird way. Weird in a SQL point of view, but not that weird when your ORM hide it for you. And then you have to understand how it works under the cover in order to avoid the normal behavior of the ORM. It usually leads to untestable code in order to achieve your goal without performance issues.
Soon after that, during the next spring planning, the users will ask for a “minor” UI change in the way we can filter data. And again, you will need to understand what’s under the cover in order to understand how to change it according to your user’s wishes. But the thing is that the theory of the framework will probably not match your program’s theory. And it will take a lot of hacky code and long hours of tests to make it work.
And this is without talking about the bugs (or misuse) of the libraries you’re dependent on. It could be quite long and frustrating to wait for other developers to fix a behavior important for your business.

Reinventing the Wheel. When people talk about “reinventing the… | by Kim  Bellard | Tincture

So what’s a wheel?

To be fair, it depends on your context, and project maturity. But basically, a wheel is something that is becoming a commodity through time (Wardley’s map could help to see and understand that not everything can become a commodity). Most famous examples might be electricity, the internet and now cloud computing.
Of course you certainly not need to build your own database, and not even to host it. But thinking that you can build a complete product by using mostly existing libraries and frameworks is also a myth.
Using other libraries to build a solution faster can make sense when you’re exploring a problem.
But at some point, you probably need to replace them with custom components where you can have a complete control. This “inflection” point is hard to find, and most companies fight to keep things as they were instead of looking to what will be required at their maturity stage.

A software wheel is something that you don’t need to care about, in your context and at your level of maturity. Hence the hard part is that it will change through time.
Try to keep an eye to understand where your bugs come from and what part of the code is harder to maintain. It might require to change “a wheel” by a custom part to take full control of the behaviors.

So do you have similar stories?

 

What’s programming

A few days ago I asked you to think about how to define your job as a software developer in a single sentence. This question is highly correlated to the question of what’s programming.
That’s why an article on the matter was pointed to me on twitter in response to my tweet on software developer’s job.

Looking for Naur’s programming as Theory building will lead you to this article.

It was written by Peter Naur (the one from the Backus-Naur Form, aka BNF programming language  syntax notation) in 1985, and it is so far one of the most comprehensive texts on what’s programming I had the chance to read.
To quote him, a motivation  “of the presentation is a conviction that it is important to have an appropriate understanding of what programming is. If our understanding is inappropriate we will misunderstand the difficulties that arise in the activity and our attempts to overcome them will give rise to conflicts and frustrations.
I could hardly agree more.

upload.wikimedia.org/wikipedia/commons/5/55/Pet...

Programming and the programmers’ knowledge

The main point of the article is that a programmer (and her team) somehow build a theory of the program when working on software, and that this knowledge cannot be totally embedded in documentation and/or code quality. Actually, the fact that different developers will build different theories explain why we will always find a codebase we have to maintain from someone else “bad”.
This is independent of the code quality or documentation unfortunately.
“The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and correction of errors in them, is essentially dependent on a certain kind of knowledge possessed by a group of programmers who are closely and continuously connected with them.”

digital knowledge image


How to treat the programmer

One of the main impacts of such a view is that developer cannot be the disposable we would like them to be in an industrial process. Quite the opposite, they will appear as key part of any success stories in the software industry.
“At the level of industrial management these views support treating programmers as workers of fairly low responsibility, and only brief education. On the Theory Building View the primary result of the programming activity is the theory held by the programmers. Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned. Instead the programmer must be regarded as a responsible developer and manager of the activity in which the computer is a part.”

How to Become a Programmer: The Complete Beginner's Guide

What’s a dead program

If we acknowledge that the team building the product is so important, it follows that the life and death of a program is not defined by the fact that it runs in production, but by life and death of the team building it. From that we can suggest that methods like pair and mob programming are must have for a long living program, because it will help the theory of the program to be distilled continuously through the team, and it will address the training of newcomers to know the existing theory.

“The death of a program happens when the programmer team possessing its theory is dissolved. A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered. Revival of a program is the rebuilding of its theory by a new programmer team.”
[…]
“What is required is that the new programmer has the opportunity to work in close contact with the programmers who already possess the theory, so as to be able to become familiar with the place of the program in the wider context of the relevant real world situations and so as to acquire the knowledge of how the program works and how unusual program reactions and program modifications are handled within the program theory.”

RIP QR Codes | Peacock Nine

And much more…

From my perspective, this article also gives insights about writing small replaceable features instead of huge monolithic one, on the importance of unit tests and on the reason why software development can’t be handled like an industrial process.
But as Florent Pellet recalls me recently, it’s always dangerous to interpret past writing with our current context and understanding.
Still, this paper is older than me, and it seems to me that it embedded many visionary wise knowledge that is absolutely not mainstream todays.
Do you have the same feeling about it?

 

What’s your job as a software developer

Because you’ll have many family’s meals in the upcoming days, it might be a good idea to train yourself in order to explain your developer job to the mere mortals in a single sentence. It may avoid the classical “can you fix my printer” or “can you check my wifi” issues. So before reading the rest of the post, stop for a while and try to think about it.



Done?
I tried it a few weeks ago, and here was my personal attempt.

I had the chance to talk about it recently with other developers of HackYourJob’s community, and it makes me realize that “In order to explain it to a computer” cannot be the goal. This is just a means. So here is a more recent attempt.

Of course the interesting thing in this thought is not the tweet by itself, but the corollaries it implies.

My job is to understand someone else job

Let’s consider this to start with. What would be the primary skill expected by someone who needs to understand someone else? Hint: I don’t believe that any technical framework will help for that. So, what if programming was a social activity?
Yes it’s important to argue that programming is not about being lonely in front of a computer. It might be a part of the job, but certainly not the hardest one.
Understanding someone else means that empathy, being able to learn fast and understanding business contexts are keys to be an efficient programmer. The best program you can write is the one you do not need to write because you found a better alternative for the business to improve without a costly software solution.

How to Really Understand Someone Else's Point of View

My job is to explain someone else job to a computer

Computers have this particularity: they do not accept ambiguity. It means that you have to be absolutely precise when you talk with them, in terms of syntax and content.
Hopefully for the syntax, compilers, modern IDE and search engine will help you. Contrary to what juniors or people outside of this industry might think, this is the easy part. Not trivial, but pretty easy compared to trying to express without ambiguity a set of business rules (ie the content).
Many people will argue that this set of rules, the so-called specifications, will be written by someone else so you won’t have to worry about them when coding. You will just need to translate. Spoiler alert: this is false.
Even if someone else tries to do it, it will never be clear enough for a computer to understand it. If a computer can understand it, it’s called an algorithm, which is nothing but executable specification when written in a specific programming language.
It doesn’t mean that having someone else to help you understand the business is bad, it just means that it won’t avoid the necessity for you as a software developer to understand the business.

10 Things Every Software Developer Should Know - DEV

My job is to improve someone else daily work

It’s tempting to believe that writing software is the ultimate goal of a software developer. Even my first tweet suggests that. But of course, software is only a means.
You can write the best software in the world, if it makes its user’s life harder for bad reasons, you are still a bad developer in my opinion. Hence ethic for example is also a major component of our work.
It also means that you can be an awesome developer if you improve someone else daily work with an excel macro. Don’t let the industry define you with technical languages and buzz words. The outcome of your job is much more than that.

Software Developer Levels: What are the Major Differences? | number8

How would you define your job in a single sentence?

In this post, I tried to express all corollaries implied by this simple sentence: “As a Software Developer I have to explain someone else job to a computer in order to improve someone else daily work.”
What are your propositions to improve it?
Or maybe you don’t agree with some of the corollaries?
Or you think I missed an important part of the job?

In any case I would be glad to hear about it.

 

Event Modeling

When was your last breakthrough about software development? I think I can resume mine in 4 steps:
1- Writing test is not optional to handle complex system
2- Good architecture is not optional to write test
3- Most programs are built with a CRUD approach, which isn’t easy to maintain in complex systems
4- Event-driven architecture may help to avoid this CRUD approach, mainly because Events can be domain concepts that we share with the business.

That’s why, coming from the DDD world I’m so interested in CQRS/ES and functional programming to handle complex systems. I’ve seen a few times already how the combination of DDD strategic patterns to handle contexts, CQRS/ES implementation and Event Storming for exploration of the problem space are efficient. It allows to get a very deep understanding of the problem, and a very robust way to implement the solution, all relying on the power of events.

Recently I’ve seen a few tweets about this “new” stuff: Event Modeling. And a few tweets later, I had the chance to organize an Event Modeling workshop in Lyon with Adam and Greg, that I had the pleasure to attend. Let me share some feedback here.

Event Modeling vs Event Storming

There is a very detailed post about what’s Event Modeling by the author Adam Dymitruk, thus I will rather give a short explanation assuming that you already know about Event Storming.
Both methods are starting in the same way: you want to “storm” events by asking business people to tell the story of their domain.
Then, you try to order the events in time to show that you can describe a business flow from start to end quite exhaustively.
From that point Event Storming (at least in the way I’m used to practice it) focus on the emergence of commands, aggregates and bounded contexts.
Event Modeling in the other hand will then focus on User Interface (UI). The goal is to add UIs to show the progression of a screen through the business flow. You will often duplicate the same screen, and just change some values to represent in which way the UIs are impacted by the events. Note that you can add different lanes to represent the UIs for different users impacted by the same events.
At the same time, some lanes can be added for the events. Some events are about inventory. Some are about payment… Yes, it’s just another way to let your bounded contexts emerge. And a very powerful one I think, because it makes clear that UI most of the time gathered data from many contexts.

Event Modeling keeps Events order

Practicing Event Modeling removes some Event Storming frustration for me.
I have facilitated many Events Storming in many organisations since 3 years now, and I often have the same feedback that losing the temporal relationship of events (when going from Event Streams to Aggregate) is a shame, because we loose meaningful information. I usually agree but answered that this relationship wasn’t “lost”, and that we could always take pictures to keep it somewhere.
Event Modeling just keep this relationship by default, and I think it’s a good idea in the end, because time matters when speaking about events (actually they’re just two sides of the same coin).

Event Modeling also focus on UI

I also observed during my Event Storming session that adding some UI sketch might help a lot to remove ambiguity.
One of the steps in Event Modeling is actually to draw all meaningful UIs for different users. It makes sense because it helps business people to have a better understanding of the “link” between domain events and the software they will use in the end. I think it helps them to translate from problem space to solution space if you will. Also, as already explain, it shows that UIs most of the time gather data from several contexts.

A different view of bounded contexts

The step of drawing contexts around aggregates like in Event Storming doesn’t exist. Instead the contexts emerge in even a better way I think: by putting events stream in different lanes depending on the things they are doing for the business.
Is it more about payment? Or inventory? Or security? We easily feel that all events do not lie in the same streams. And each stream of events might in the end represent a different bounded context.

A CQRS cycle keeping track of time

Last but not least: Event Modeling results in a “true” representation of a CQRS/ES system. We know the classical circular view in a CQRS system: View -> Command -> Event -> Model.
What does this circular system look like in time? Waves of View -> Command -> Event -> Model -> View -> Command -> Event -> Model … and so on.
In the end, using this Event Model as a blueprint for the software we are building makes sense, because it doesn’t miss any component that matters for business. We have the domain events and we have the UIs, and all the transition leading from one UI to another following the pattern View -> Command -> Event -> Model .

Finally, a silver bullet ?

I’m not an expert of Event Modeling, and like anything new I probably miss some disadvantages of this method due to my feeling that it removes many problems I met in my current way of working.
But I’ll try to use it very soon, because I see lots of potential in this approach.
I can see how it helps me to be closer to the solution space, with still something making sense for the business.
Something I already feel harder though might be to know how to represent aggregates with it. Actually this is probably due to the author view: he doesn’t really care about context or aggregate; but rather about streams. An event stream is a “logical” stream of events… Ie either a context or an aggregate depending on the context I guess^^

Anyway, I will try it and let you know how things are going 😊

 

What if programming was a social activity?

It is well known today that building software is a really personal experience. Old studies have proven that the best software engineers don’t like people. According to M. Cannon and Dallas K. Perry, they dislike people activities involving close personal interaction. Hopefully it totally makes sense doesn’t it? Just to have fun, let’s imagine what would happen if this fundamental assumption of the IT industry was wrong.

A wrong culture might have emerged

Women are usually better in terms of soft skills like empathy and humility. If programming was a social activity, the initial bias in favor of men with the stereotype of the coder geek playing Dungeon and Dragons in his basement would have created a totally wrong culture. With more women involved, we may talk much more about people, ethics and other unproductive stuff. But we avoided this nightmare, most discussions are about the last Framework shipped by any big companies, which is much more productive and keep our industry sanity safe. 

Evaluating individual performance would be a nonsense

The second problem would be in terms of management. How the hell could you know which one of your employees deserve the best paycheck if what they produce is a global teamwork? And probably more important: how would you know who to punish in case of failure? In such a case, the whole management principle from Taylorism and Fordism would need to be changed.
Also that would highly discredit the 10x engineer fact! If you have a 10x engineer as part of your first few engineers, you increase the odds of your start-up success significantly. Because building a startup is mostly about coding something in your basement or in your student’s room, not at all about experimenting fast and understanding people.

Working in group would be a common approach

Can you imagine that? Two people behind the same screen at the same time? Do we need two people to drive a car? Or even a train? Of course not.
And what if they work with more than 2 people? All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer?
That would mean that building software might be harder than flying a plane or doing some surgery? Let’s be serious, telling a machine what to do cannot be as complex as these disciplines, which require a high level of study and a long-life practice to be mastered.

The IT industry would be a perpetual crisis

I think the best argument is that most software project would have been a failure during the last 70 years if software programming was a social activity. Most projects would have been over time, or over budget, or even not release at all even though they cost lots of money.
If that was the case we would already have heard about it and fix it right?

What if programming was a social activity?

Anyways, I think I’ve demonstrated why programming cannot reasonably be a social activity.
Of course, if developers were responsible for critical infrastructure, or if they could code decision about human life, maybe that would make sense?

Ho?… Wait…

 

The systemic failure of the IT industry

Let me tell you a story.
This is a story about a brand new software project, using last technologies and mobile devices, a really important project for BigCorp. They want to use this new product as a vitrine to show how good they are to create mobile applications.

The gold rush

BigCorp invests a lot on this project, quickly a team of 15 people was created. 1 project manager, 1 assistant project manager, 1 scrum master, 3 business analysts, 3 testers 1 architect and 5 developers.
Everybody wants to be in, the global mood was very good, all the requirements were clear, this will be the best project we’ve ever seen.

Sprinting to reality

After 3 weeks it was time for the first release… And the first deadline was missed. Less than half of the expected User Story were produced, and the code was really brittle.
During the retrospective (where project managers and business analysts were missing because they are busy) it was decided to do less automating testing and less refactoring, because it was obviously a lot of time invest in unproductive stuff. We need to deliver more User Stories.

Wall ahead

The project is now 1 year old. Half of the team was replaced. One of the business analysts was fired because he “screwed” up a demo to the company board. The mood is no longer that good. The requirements were not clear enough after all, it’s even hard to know who the users of the system are. The technology is no longer shiny because 2 new frameworks have been created during the year and seem much cooler.
The software is still really brittle, which leads to even less refactoring because “we don’t want to break it”. New attempt to add unit tests were made, but it “costs” too much, this is obviously “not possible for us to do unit testing”. Retrospectives were stopped, because who can afford one unproductive day?

And yet another awful legacy

The project is now 5 years old. No one from the initial team is still working on the project. The team is only 1 developer now, half-time. We ask her to “maintain and fix bugs” that users will find. The code is a nightmare to work with. We have no idea of what is done, and how it’s done.
It creates lots of frustration for the developer, and for the user.

Failure = lesson learned?

Not really, it’s just a normal software project in BigCorp. It’s actually so common that most people in BigCorp think that software projects are always going this way. From developers to the top management, no one is shocked anymore, this is how software project works.

What can we learn from BigCorp?

Software of big companies and governments are usually pretty bad. Because the product is just a mirror of the system that produces it. A system with lots of hierarchy, politics, arbitrary deadline and silos. A system with no idea of the level of communication and collaboration required to achieve great software. A system where the customer does not really exist, because the company is too big to care about them. A system that erases the creativity required for good software.

Most companies have systemic errors. They produce bad software, no matter how skillful the employees are, because the system pushes them in bad habits and make them believe that this is the only way to go.

This explains why it’s so hard to create good software. It’s not only about technical practices and principles, this is also a lot about the system in which this software is produced.

PS: Thanks to Anthony Cassaigne, and on the recommendation of Woody Zuill, I finally read the paper “Nobody Ever Gets Credit for Fixing Problems that Never Happened”. I highly recommand it, many echoes with this article !

 

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.

 

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.

 

 

 

Release your Soft Power

A few weeks ago, an interesting discussion arises on twitter (in french, sorry for my foreign readers).
In a nutshell, it all started from a (french) post by Arnaud Lemaire about why he hates developers contest, where he explained that this kind of behaviour is infantile. Thomas Pierrain explains why he agrees, and it triggers a long thread with many french crafters about:
– Is the IT industry mature or not?
– What is our responsibility as developers?
– What is the responsibility of the company we are working for?
– Can we change an organisation to improve practices? Should we?

Of course, I don’t pretend to provide any answers to these fundamentals questions, but as usual twitter is not the good medium for long discussion (even if in this case the thread was really kind and friendly). I would like to summarize my comments here, in english to be more inclusive because I guess these topics could be interesting for many software crafters across the world.

Is the IT industry mature or not?

I won’t comment much this point because I already explained here why I think it’s not. I understand that everybody has not the same feeling about it, and it’s fine. In any case I think we can agree on the fact that there is a long living software crisis, which at least shows that we can still improve by an order of magnitude.

What is our responsibility as developers?

Our responsibility is to be professional, which means that we must be aware of the good practices in our industry, and up to date with them. There are technical good practices (unit testing, continuous integration…) and soft skills good practices (good communication, reach the business experts, empathy with users…). Most of us are aware of the former, few of us are aware of the latter. When you do apply both, you are no longer a simple blue-collar technician. You become a business involved people, you release your soft powers. You’ll more likely be part of the important decisions. I think it’s what Thomas means in this (french) keynote when he talks about “changing your developer posture”: take your full responsibility to reach your full power.

What is the responsibility of the company we are working for?

Of course it is also a bit controversial. What if the company I’m working for does not allow me to reach the business experts directly? What if I can’t see any users? What if they don’t even allow pair programming, or unit testing, or continuous integration? That is the point where the company does have a responsibility. And the first answer is: try to change it with a local change of the practices.

Can we change an organisation to improve practices? Should we?

In the twitter discussion, many people testified about the fact that you can’t change an organisation as a developer, because you’ll need managers support for that. I do agree, and I don’t care at the same time. I’m a huge fan of Gandhi on this matter: “Be the change you want to see in the world”. Why would you change a full organisation? It was here before you, it will stay after you, and it would be pretentious to suppose that you know better than them for their whole company. But, as a professional software developer, you do know how to manage the software you are working on. This is where you can (and must) have an impact: locally. If your team, and potentially a few teams around are convinced about these practices, it should be enough to live with. And it’s not such a big deal if the rest of the company is not aware of these practices. A local impact is about improving the software quality through technical practices, and your co-workers’ life through soft skills.

Last question

It now raises a last question: what if the company resists change? What if they explicitly refuse technical and soft skills good practices? In that case my advice is really simple: leave. The world is full of companies looking for competent and passionate people. Leave and work for them, or even better: work for yourself as an entrepreneur, to create a place where other passionate people will be happy to work.

 

The Software Evolution Hasn’t Happened Yet

If the hardware has followed the Moore’s law, what happened to software? We have built assembler, and compiler, and high-level language. And now we have powerful machines, and all these shiny new languages and frameworks promising productivity. So why the hell are we still providing lame software?

The software crisis

According to Wikipedia, the term “software crisis” was coined by some attendees at the first NATO Software Engineering Conference in 1968. The crisis manifested itself in several ways:

  • Projects running over-budget
  • Projects running over-time
  • Software was very inefficient
  • Software was of low quality
  • Software often did not meet requirements
  • Projects were unmanageable and code difficult to maintain
  • Software was never delivered

That’s a good sum up of the problems I’ve met in 10 years of recent software development. And apparently, I’m not the only one, some of us talk about a software apocalypse.  It’s both confusing and sad to see that our industry’s perception hasn’t changed. What could be so hard about software? Why do coders write so much bugs?

The software labor

Software has always been, and still is, underestimated. Have you ever think about the names, hardware and software? These names reflect the roots problem of our industry. We believed that the building of physical electronical device will be the hard part. Nobody has anticipated the fact that programming these machines could be complicated. That’s why the first software programmers were women. We cannot be proud of that, it was just because some highly respected (male) scientists of the 50th believed it would be an easy task.

This fundamental misconception is still widely spread today, especially for people who never tried to build a software by themselves. It explains partly why our profession is underestimated and poorly managed. Very few people understand the implication of a “soft” device. Thus, they try to apply what Fordisme and Taylorisme has taught to them: hire some managers to manage an army of low qualified people to work on chain production.

The software engineering

Software is, by definition, not a physical thing. It removes constraints, physical and temporal. You want to change a past event? No worries. We can build rules, and break them as we wish. You want to change a behaviour? Let me add a few conditions. We’re not constrained by time or space. Not even by logic. We are only limited by our imagination. (And a bit by the computer power and the money we’re supposed to earn with the software. But as hardware is really performant, and because IT generates so much money, the main limitation is still our imagination.)

How do you build a bridge? By a series of calculation and drawing, taking in account a huge number of parameters from the physical environment, in order to use the laws of physics to assemble physical components in something that will stand for a while. But mathematical and physical laws do not apply to a soft world. A world where almost any rule can be broken. A world where the number of possible states can be greater than the number of atoms in the whole universe. Standard line of business applications have a complexity that we cannot manage (it is common for us to not accept this fact). And to add more fun, even if we manage to make it works pretty well, we are still not sure that it will solve any actual problem.

A doom’s profession?

Rather a huge opportunity I think, because software root problems are the same since many decades, we can be the actors of its evolution, and learn from our short history. From the easiest to the hardest, here are a few propositions to improve our craft. Sorry if some might seem obvious, but as a software professional, I’m in a good position to know that it is not.

Let’s start with the basics: automating tests. I won’t re-explain here why and how. But we need to acknowledge that it is currently one of the best way to manage this invisible complexity. A series of automated tests to validate the behaviours of the software as it evolves. It’s a way of feeling what we are designing. Like with WYSIWYG, we want to see immediately when an expected behaviour is broken, and what will be the impact of our modifications.

Another point is to use less states and more types, because it is where the complexity hides. Mathematically, specialized types do reduce the number of possible states in functions outputs. Solution like Property Based Testing can help to test the limits of such systems.

A harder way is to understand the problem we are trying to solve. There is no clear separation between the pure technic, and the design of an appropriate solution in software. Which explains why there can’t be a clear separation between the maker (the coder) and the the thinker (the system designer). To be good, we need to understand the business and to be technically efficient. This is where Domain Driven Design and relative stuff like Living Documentation can help.

And finally, we can learn and apply more maths in our code. It fundamentally adds some laws in our chaotic soft world. Some laws that will highly improve the code, like avoiding side effects and mutable states. This is where Functional Programming and TLA+ can help.

Think out of the box

Finally, we need to remember how young is our industry, and the fact that we’re living a crisis since the beginning. It means that we need more imagination to solve our problems. For that, I encourage you to listen to people like Alan Kay or Victor Bret, and to learn about our history. What if written software is just not the good way to make it? What if we are still living the dark age of software development?

We build a lot from (too) small foundations, maybe it’s time to challenge ourselves.

 

Of course the title of this post is a refererence to an amazing OOPSLA conference by Alan Kay: the computer revolution hasn’t happened yet.