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.

 

In defence of defence of Software Craftsmanship and Uncle Bob

I hope some water has gone under the bridge after the “Google memo gate” followed by the “Uncle Bob is a misogynist gate”, so let’s discuss it again. During a few days, I feel almost uncomfortable to read Twitter. I read many anger reactions, many accusations and a few smart comments. I’d like to share my feelings in this post, because I believe I’m not the only one to feel bad about this thread.

In defence of software craftsmanship

I’d like to thank Daniel Irvine to have written a good post to defend software craftsmanship. I won’t rephrase here what he already said, but I would like to testify as a software craftsman. I came to this community explicitly because I was not looking only for technical excellence. And I think it is the case for most crafts(wo)men I know. It is an open minded and friendly community.
I feel that even more due to recent events, because at every new attacks in Paris, London, Barcelona or Turku, I can think to crafts(wo)men living here, and I hope nothing bad has happened to them. If I care about them it’s because I know we share some values and principles. Not only the quest for technical excellence, but also a deep respect for people, a willing to improve the things around them and to share their passion. I feel connected to them.

The software craftsmanship community is by far the place where I’ve met the more activists. They talk a lot about ethics, politics, environment, and of course diversity. I can’t remember a single SoCraTes I attended where several of these topics were not discuss. And it is important to me, because I know I must improve about them. Of course, it is not perfect, it is often the same people who talk about these topics. But please don’t assume that other people don’t talk about that because they are not interested. They don’t talk about that because like me, they are often part of a favourited majority, and don’t feel legitimate to discuss such topics. I know it’s wrong, I don’t try to justify it, I just try to explain how I feel, and why I need to change.
As a software craftsman, I would like to testify that this community is certainly not a bunch of old white men who care about TDD. To be honest, this is the community where I see the most diversity, in terms of country, sex, religion, and skin colours. I agree it is still not enough. But it is unfair to say that this community only care about technical stuff.

In defence of Uncle Bob

But I think we missed a post to defend Uncle Bob as well. I’d like to thank him for the many good, talks, books and blog articles he has written. He was the one who enlights the passion in me with Clean Code.
Of course, he has done some bad stuff as well (but who doesn’t?), and I don’t agree with every word he says. For instance, I don’t believe working 70 hours per week is mandatory to be a good software engineer. And no need to say I don’t believe that you should not fire someone who has toxic ideas.
But his point was more subtle: “Don’t fire someone just because you disagree with him”. I think his example and context was bad, but it raises a fundamental question: how do we differentiate toxic ideas and ideas we disagree with?  It’s a fair question because if we don’t agree with toxic ideas, aren’t we tempted to label as “toxic” any idea we might not like? How do we react with people who label agility, scrum, XP or craftsmanship as toxic?

I don’t have the answers, but my point is that the community has overreacted. Yes, the example was poor, yes, the context was bad. But instead of asking for explanations (that he writes here), and discussing the core question (how do we differentiate toxic ideas and ideas we disagree with?), there was lots of anger and unrational discussions about since when and how much Bob is a misogynist, and if we should refuse him to speak in conferences. Aren’t we open-minded? Aren’t we here to help each other? Uncle Bob is a master of technical stuff, but he says that he needs to improve on the topic of diversity. Like me, and like many other average white men in the industry.
The solution is not to ignore him and label his speech as “toxic”. The solution is to discuss, argue and teach, because we are all smart software engineers who share values and principles, including the willing to improve, and not only technically.

As a software craftsman, I would like to testify that this community is very open minded, and that it can help people to improve, even Uncle Bob.

 

Developers don’t like people

Any idea who are William M. Cannon and Dallas K. Perry? Neither do I until a few months ago, and that’s a shame because they have a part of responsibility in the image of software developers. They have discovered that we don’t like people.

sans-titre

How do you hire for a new job?

Recruiters are still pretty bad to hire developers. Mainly because they don’t understand the job we do, despite the fact that software is everywhere in our lives. But imagine when software were not mainstream, they have to hire thousands of developers with absolutely no clue of what a developer is.

Still, big IT companies in the 50’s and 60’s have to find them, so they commissioned two psychologists (William M. Cannon and Dallas K. Perry) to look for the profile of programmers.

I bought the paper they wrote in 1966. It is interesting to note they were looking for happy programmers, more than good programmers. Indeed they use the Strong Vocational Interest Blank (basically: a MCQ to find your interest in different areas) to profile 1378 computer programmers. Then they build a scale to predict how happy someone could be as a developer.

happyprogrammer

Paper quotes

“Long ago, E. K. Strong, Jr. advanced the notion that individuals interested in the same activities and things, whether these were directly job-related or not, tend to find satisfaction in the same type of employment.”

“[…]it was anticipated that a new scale for measuring the interests of computer programmers might be developed. Such a scale would be especially valuable in counselling, guidance, and recruiting as a way of identifying appropriately qualified persons so that someone could say to them something like, “Hey, you there! Your future is in computer programming!”

“The interests of computer programmers were found to be most like those of optometrists, chemists, engineers, production managers, math- science teachers, public administrators, and senior certified public accountants.

“Responses of programmers to individual SVIB items, when compared with responses of other business and professional men, showed three things. First, they indicate that computer programmers are crazy about finding the answers to problems and solving all sorts of puzzles, including all forms of mathematical and mechanical activities. Second, they don’t like people — they dislike activities involving close personal interaction; they generally are more interested in things than in people. And third, they show a liking for research activities and a tendency to prefer varied and even risky activities, while at the same time avoiding routine and regimentation.”

“Although these scales can predict satisfaction in the field, they cannot tell us how good a programmer an individual is likely to be.”

pgmer

A fundamental mistake

I’m not a psychologist, but still believe this analysis have some serious errors.

I can’t understand where the conclusion that we don’t like people comes from. Worse, I imagine some candidates who might be rejected because they do like people!

This assumption hurts our industry a lot. The most challenging part of big software project is people management and communication. This is exactly what agile methods and practices like TDD, BDD, DDD and pair/mob programing are trying to fix since decades.

Assuming that we developers should not like people is a huge mistake, and denies the fact that good software is mainly a good team work. Maybe lots of happy programmers don’t like people, but there is no need to “like activities involving close personal interaction” to be a good co-worker. Trust, respect and honesty are usually enough.

Good programmers are good co-workers before all.

avengers

A shared responsibility: the media

Responsibilities are most often shared, no need to look for a single culprit. Media also take a part in the image of software developers. In every movie with a geek I remember from the 90’s, the geek was a stereotype of the introvert puny guy with googles.
Interestingly enough, our image has kind of evolves. There are more and more movies/series where we are the heroes. But there are still lots of efforts to do to improve diversity in our representation.

serie

A shared responsibility: us

This image has become natural for us too, and we might look for it when trying to hire a good engineer. Aren’t we skeptical when speaking with a good looking person in a suit for example? I guess we hire ourselves for a while, and are still assuming that the little guy with googles is probably a better programmer than this attractive girl.

So let’s take our responsibilities and fight our own biases, especially when hiring software developers.

 

 

Thanks Sylvain Chabert for sending me this article, it inspired this post.

PS: I don’t really know where to put it, but I really like Reinstedt’s discussion of the paper. Thus here it is (or at least a part of it)

“I’m reminded a little bit, since I did research on the Strong Vocational Interest Blank a couple of years ago as part of the Com9uter Personnel Research Group, of the supposedly true story that I heard in some work that I was taking in psychology.
The story is that in New York many years ago, during prohibition days, several psychologists from different disciplines of psychology–social psychology, religious psychology, social welfare workers, etc.–did work to find out why the people were on skid row, how they got there. The social welfare workers found they got there because they came from underprivileged, socio-economic homes; the religious counsellors found they got there because they had lost God along the way; and the other psychologists found different reasons why they got there. Prohibitionists said they got there because they turned to John Barleycorn. So it strikes me as a little more than interesting that certain results that I thought I would get, I got; and results which are contrary to these which Dallas and Bill thought they’d get, they got.”

 

 

Usable Software Diagram

“Who is the user of software design”?
Some Software Usable Design practitioners think that the user is the developer.

I think the answer is not the same in every Dimension.

kk-studio-1

The user of software design is the developer

Specifically in the Artefact dimension.
Maybe it was the first answer to come in mind, because the question was initially asked by some developers.
The developer uses the design to build a mind map (with abstraction and static representation) of the software. With this map, she is able to navigate through the codebase in order to achieve a feature or to fix a bug.
She will technically explain to the machine how it should behave, but other humans will need to understand these explanations. A good design will give a frame to help the developer to put responsibilities in the good place.developer-512

The user of software design is the final user

Specifically in the Runtime dimension.
If a user has to read our documentation, it is a failure and an opportunity for improvement.
The software design must be crystal clear for the user at Runtime, because she will also build a mind map (with dynamic representation) of the software.
Not the same map than the developer, because it has different purpose. But still the user will navigate in the UI thanks to this map, in order to achieve what is useful to perform her job.

add-user

The user of software design is the business

Specifically in the Decision dimension.
And the whole purpose of DDD is to bring back this reality as soon as it is forgotten in the Artefact or Runtime dimension.
Again, the business build a different mind map (with business use cases), and uses it in order to take decision. The goal is to improve the business using the power of software.

business-person-silhouette-wearing-tie_318-49988

Navigating with our own map

The map metaphor is really powerful, and Eric Evans himself uses it a lot.

I also like this talk by Simon Brown about the Art of Visualizing Software Architecture. He compares the drawing of an architecture with the drawing of a map. His point is that we need to know for who is our drawing, and why. Because any representation is an abstraction of the full system, and we need to understand what will be done based on our drawing to choose the good abstraction, at the good level.

Software design is used to navigate in the understanding of a software system. For this navigation to be efficient we want:
– a consistent level of abstraction
– abstractions align with our dimensionimages
Usable Software Architecture Design
A Usable Design needs to be navigable.
A good visualisation for our Software Architecture will let us know if our design is usable or not in terms of navigability.
Taking into account the dimension will help to build useful and navigable abstractions, because it implies a specific user in a specific context.

Don’t fall into the trap of mixing scale, or dimensions, in the same drawing. It will only result in a messy diagram that we’re used to see in our enterprises.

Instead choose one scale and one dimension to build understandable diagrams for one purpose.

 

The Technical Debt Myth

We assume that less design effort allows producing features faster, in the short term.  Less design effort generally means less abstraction, and tighter coupling, in order to produce working code faster.

But we tend to overlook the fact that it slows future modifications, even of unrelated features, because of tight coupling. We usually call this fact « technical debt », the term was first coined by Ward Cunningham. A better name was suggested by Steeve Freeman: unhedged call option.

option

Financial debt vs. Unhedged call option

Financial debt is predictable. You know how much you get, and how much you will pay back. A debt could be useful from a business perspective. A cash boost at the right time can create a major competitive advantage.

An unhedged call option also comes from the financial world, and is a really risky operation because it has unlimited downside. The buyer pays a premium to decide later if he wants to buy. The seller collects the premium, and will have to sell if the buyer decides to buy. It is not predictable for the seller.

Transpose to software, the difference with the concept of debt is the predictability in the amount of work required to fulfill our engagement.

When we write crappy code (tightly coupled and without tests), we collect the premium: we immediately get benefit from the new feature.

But as soon as we have to maintain or evolve this codebase, the option is called, and we have to pay an unpredictable amount of time (thus money) to achieve our goal.moneystack

Why? Who?

Every time this kind of tradeoff is required, we should ask who is asking for this, why, and who is going to pay it. Fun fact: those who ask for it (and directly benefit from it) are not often those who will pay it.

The sales team for example may ask for a quick hack because the customers « really, really need it yesterday ». But it may be paid by the production team, because next time the customer will want something, we still have to produce it quickly, without any regression. That’s where we will support more pressure, and may do some overtime.

In the end everyone will be impacted, because more pressure means more bugs, more regressions, and finally unhappy users. No company can survive unhappy users forever.

That‘s why good design matters. We want to produce current and future features in a sustainable and predictable way. sustainable_development_and_you

But what‘s good design?

We all try to do our best, but some of us lack knowledge and/or feedback. Plus, good design is contextual.

But regarding of our context, good designs have common points. It allows to think clearly about our software, and to evolve it easily. It allows to know where we should add/modify/fix a feature. The evolution-ability gives us an option on how to add/modify/fix this feature.

Software must be able to evolve because we know we don’t know what the software will be. We must design to be able to discover (as explained by Dan North in the 3 ages of innovation)

Decoupling is then required because we need to think about small parts in isolation, without side effects.  This kind of good design allows producing predictable software: robust, resilient and without regression when it evolves.

If we use shortcuts, and couple our code in order to rush it into production, we must be aware there will be an unpredictable amount of time to pay to get back into a predictable state.
It does not mean we should never do it, but we all have to understand this trade-off before asking for a “debt”.

decoupling

What about speaking of predictability?

The more shortcuts you take, the less predictable your software will be. If you pay more for well design software, you get the opposite effect.

Unfortunately it is hard to judge, as we usually think we design software well. A good way to know if we are on good track is to rely on how predictable is the software we produce. Are the customers happy? The production team? The sales team? Do we have very few regressions? Do we produce features at a regular speed?

If not, we should consider investing more on design and refactoring, before entering into a vicious circle of unmanageable software.

Order Or Chaos Directions On A Metal Signpost

The technical debt Myth.

That’s why the comparison with a financial debt is sub-optimal. Money debt is predictable, whereas software debt is not. Unhedged call option is a better name, but still comes from the financial world.

Maybe we should stop financial comparison and speak of predictability instead. I find it is a better description of the consequences of shortcuts in the design.

 

 

Thanks Brian Gibson, always here to help me to improve!