Forem: Arne Mertz

Code of Conduct - why I Insist

Arne Mertz — Fri, 23 Mar 2018 17:58:24 +0000

This is a cross post from my personal blog.

I have had a lot of questions and discussions lately about the necessity for a code of conduct at conferences. I boycott any conference that does not have one or is inaccessible to many for other reasons. Here's an off-topic, out-of-band post about my thoughts on this.

The tech community, and maybe especially the C++ community, is a white-male-dominated culture. It is no secret that there have been various incidents at different conferences of sexual, sexist, racist and homophobe harassment. Sometimes it is not that bad, but that does not mean there is no "locker room talk" or the simple feeling that minorities are simply not welcome.

Besides the fact that this situation turns away a lot of talent from our industry, it turns away a lot of people from what they like or would like to do. That's why I think steps towards making our communities more inclusive are dearly needed. Having a code of conduct at conferences is among the easiest.

What a code of conduct is and does

A code of conduct is often seen as a tool to enable conference organizers to deal with attendees who harass other attendees. If we look closer, it's not that, but much more. It's a signal to every person attending or interested in attending.

First of all, it's a signal to everyone attending the conference, that they are participating in an event where douchebag behavior is not tolerated. There always will be someone who does think such behavior to be generally acceptable. The code of conduct tells them "Not here!". It probably won't change their mind, but it is likely to make the conference a much more pleasant experience for everybody else.

Secondly, it's a signal to minorities interested in attending a conference. A code of conduct signals that they are welcome and that the conference organizers intend to protect them from harassment. It can make a huge difference in how safe and welcome people feel at the conference.

In the end, if something actually happens, a code of conduct also is a signal that the conference organizers care. It tells the victims of harassment that when they tell someone, they will be heard and something will be done.

"But..."

I've heard lots of "but"s against a code of conduct. Here are some answers to the most frequent ones.

"... only nice people come to my conference."

So you think. In every group of people, there are some that don't play by the general rules of society. The larger the conference, the more likely it is to have some bad apples among the attendees. And it takes only one idiot to ruin the experience for one or more of the attendees. Better not take any chances.

"... nothing has ever happened in my community."

As far as you know. Being harassed sexually or otherwise can be very humiliating. Most victims are not likely to tell a lot of people about what happened. Especially not if there are no clues - like, say, a code of conduct - that they will be listened to.

"... I'll deal with assholes anyway, I don't need a code of conduct."

Of course, you will, because you probably are a decent person. You know that, and anyone who has met you knows that, too. Potential attendees who are afraid of being harassed probably do not know that since they have not met you yet. That means you have to tell them. Guess how.

"... it does not solve the underlying problems."

That's right, it doesn't. It does not solve world hunger either. Neither does the conference, by the way. That a code of conduct does not solve some problems, does not mean it's a bad thing. It also does not pretend to solve the problems of diversity, inclusion and some people being douchebags. Except that when we openly have a "harassment is not OK" policy openly everywhere in our society, it might help a little. At least it's better than doing nothing.

"So, should I just copy something from Wikipedia to my conference website and that's it?"

While you can find good texts for a code of conduct on the internet that you can simply copy or link to, there's just a tiny bit more to it. You should mean it, i.e. you should be prepared to actually do something if something happens at the conference. Most conferences I have been to have a short introduction speech where the organizers point out that there is a code of conduct.

Remember, it's mostly about signaling, and not everyone reads everything on the conference website. Shortly tell the attendees what the CoC is about (and that you probably won't need it), and who they can contact in case something happens to them or someone else.

If you really care about diversity, you could, of course, go further and have special slots for sessions about inclusion.

Conclusion

It's not much to ask to have a code of conduct at conferences. It does not take much time to put it on the website, and even less time to tell your attendees about it at the start of your conference. For my part, I won't attend or even speak at a conference that does not have a code of conduct. For what it's worth, I also won't go to conferences in countries where people are harassed by lawmakers, police or border officials because of their land of birth, religion, sexual orientation, ethnicity or whatever other petty reason.

Luckily, setting up a CoC and saying a few words about it at the start of a conference is really only a minor distraction. Much less than incidents of harassment are. And, tbh, much less than the endless debates against a trivial thing that has only positive consequences.
— Arne Mertz 🌍 (@arne_mertz ) February 9, 2018

Further reading:
Chandler Carruth: Conferences, Inclusion, and My Axe!

Simple and Clean Code vs. Performance

Arne Mertz — Fri, 27 Oct 2017 05:03:10 +0000

This article was originally published on my personal blog "Simplify C++!". In almost three years and ~140 posts, it is the most discussed and most visited post I have ever written. Simplify C++! is a blog about modern C++ and Clean Code.

One of C++'s strengths is that it is possible to write very performantÂ code. But does that mean we always have to worry about performance and write our everyday code as performant as possible?Â Should weÂ give up simplicity for performance? Do we have to?

I don't think so

There are many reasons why I don't think we should sacrificeÂ simple and clean code to write more performant code per se. In contrary, I have been criticized for advocating the sacrifice of performance for simplicity.

I would prefer if everyone wrote simple and clean code by default. OK, that's pretty obvious, because that's what my blog is all about. Â But what about reasons why I think so? Here are some.

Performance is not efficiency

ThereÂ is an important point to get out of the way first. We have to distinguish between efficiency and performance.Â What is the difference? In very simple terms it is how fast you do something (performance) vs. how long it takes to do it (efficiency).

At a first glance that might sound like it's the same, but it's not. Imagine you have to go from point A to point B.Â Efficiency means you go the shortest way. Performance means you run instead of walking. So if you run as fast as you can around the whole block to get to your neighbor, you are at high performance, but not very efficient.

In programming, loops often contribute much to program run time. Here, performance would mean that a single loop cycle executes faster. Efficiency means that you have to do fewer cycles, mostly because you have a smarter algorithm.

Sometimes you can not have the best of both worlds. The steps of a more efficient algorithm may be less performant. However, before you try to squeeze the last bit of performance out of a piece of code, make sure it is efficient. Only if you have tested all possibilities in terms of efficiency it can pay off to worry about performance.

Sometimes it is enough to make your code more efficient to get the desired speed without having to worry about performance details.

We don't need performance everywhere

This one is obvious, but many programmers, especially new programmers, tend to overlook it. There are tons of questions on forums and StackOverflow, asking about how a certain piece of code can be optimized. When one asks the counter question if the code is really a performance bottleneck it most often turns out that it is not.

There is a saying that 80% of the runtime of a program is spent in only 20% of the code. Some say it's 90/10. The exact numbers are not very important in general. TheÂ crucial point is that the program spends a lot of time in a small amount of code.

On the other hand, that means that most code does not contribute much to the total run time, and if weÂ optimize the hell out of it we won't see much of a result if we see anything at all.

Don't optimize codeÂ that you have not proven to be vital for the overall program performance.

We don't really know how to write performant code

I know, how can I dare to say something like that. The fact is that one of the major contributions to program runtime is the number of instructions the processor has to execute. And those are not written by us, but by the compiler and its optimizer.

OptimizersÂ come in all shapes and colors, and unless you are an expert in the field, you can't even guessÂ what they will do to a nontrivial piece of code. Optimizers can eliminate temporary objects, they can inline functions, sometimes even at link time, and they can shuffle around and eliminate lots of those instructions.

So, with those superpowers in the machine and our complete ignorance of what code will give the best result, what can we do to make our code more performant? At first, nothing. And if we really have to care about performance, we can not rely on our imagination or experience, we have to use a tool.

By default, write code for maintainability, because it might be as performant as anything else. If you really have to improve performance, use a profiler.

Of course, this does not mean you should prematurely pessimize. IfÂ there are two or more ways to write a piece of code that are equally readable, use the way that will probably give the best performance. For example, use ++iter instead of iter++ if you don't save the result of the expression, and so on.

Performance and simplicity don't always contradict each other

The other major contribution to program run time, maybe even more than the number of instructions, is the layout and structure of data in memory. There is a great talk about getting better performance by using the right data structures by Chandler Carruth, so I won't go further into this.

All I want to say is, ifÂ the memory layout of your data is bad, much of the runtime goes into the fetching of data from memory and saving a fewÂ instructions won't have as much of an impact as using the right data structures.

Make sure you use the most performant data structures before you start tweaking your code for more performance.

There is another point to writing performant and simple code: Using the libraries you have, and using them right.Â Those library writers usually are smart guys and know how to write performant code. They particularly know how to use their profilers.

So if you use libraries instead of rolling your own solutions, your code is likely to be not only more robust and simple to maintain, but also to be more performant.

Know and use your libraries, unless your profiler showed them to have badÂ performance.

Conclusion

Write readable and simple code by default. If youÂ actually have a performance problem and have located it, there are still many options that are more promising than turning your code into a fastÂ but unreadable mess. Sacrifice simplicity for performance only as a last resort, and always use a profiler when you are dealing with performance problems.

Testing as a Developer

Arne Mertz — Tue, 12 Sep 2017 20:20:27 +0000

This article was originally published on my personal blog "Simplify C++!". Simplify C++! is a blog about modern C++ and Clean Code.

My current employer has a company blogÂ with some pretty goodÂ content. One of the posts is titled 'What’s wrong with: “I don’t write any tests since I am not a tester”?' - which made me think about the relation of developers to testing, and about the self-image of any developer who would say that sentence in earnest.

To test or not to test

So, what is testing about? It's about checking if something works. WhetherÂ you write a new piece of code,Â or whetherÂ you change or even just delete it, you have to check if it does what it's meant to do.

Have you ever changed a source file and just checked it in, closed the ticket and maybe even went home without any further verification that what you just did was the right thing to do? I have. I guess everyone has. And what happened next most surely is one of the following options:

The CI or build server sends you a mail that there is a build failure or that some automaticÂ test failed.
An angry coworker knocks at your door, because he pulled the newest code, got a build error and spent some funÂ time researching where the error originated and who checked that piece of code in.
Some annoyed tester sends back the ticket you just closed because the problem is not fixed at all.

There are lots of other possible outcomes. However, for anything that involves more than fixing a stupid little type, the one outcome that is least likely is that really everything goes as you intended right away.

What to test

So weÂ do have to test the code changes we implement. The question is: how much should we test, how thorough should our tests be?

There are three to four things we should test after changing code:

Is the program still executable?Â This certainly includes a compilation of the translation units affected by the code change, but it does not stop there. You may need as much as a full build involving the linker, a deploy to the target platform(s) and even a smoke test.
Does theÂ change have the desired effects? Is the bug really gone, orÂ does the feature you implemented behave as specified? Are corner cases covered?
Does the change have no undesired side effects? Make sure that what you just did only does what you intended it to do. There should be no regressions, it should not change or break other features, and it should not affect performance and other usability metrics.
Is the code quality still OK? This is a little less definiteÂ than the other points, but it still matters. Some may see this as a secondary issue, because internal code quality is not visible to the user, so it has no immediate customer value. However, unless you throw away the code in the near future, bad code quality can severely compromise your ability to maintain your code, which will in turn have an impact on the customer value.

But it's not my job/role, we have QA for that!

Oh, but it is.Â Our job is to write working code. So, unless we know as a fact that our code works, we are not done. Period.Â Our job description is not "type random characters in source code files", and it never will be. Such jobs are usually paid very poorly, usually with a banana or two per day, not more.

That does not mean that QA is not needed.Â A tester is the safety net for the developers. They make sure that the code does not only work as the developer thought it should work, they check that how the software works corresponds to how it should work.

Their job is not to play the other side of endless task ping pong. Whenever a tester sends a task back to development, something went wrong. Ideally, in such a case not only the problem should be fixed, but also the cause for the problem should be investigated so it won't happen again.

How to test

I'll go back to the four different things we should tests, because weÂ might want to test them differently.

Build and deploy will always be the first thing to do, so it will naturally the thing we'll do most often. As programmers and - according to the cliche - tech addicts, we should use our talent and the tools at hand to do what we do best: automate the build.

If anything we have to do as frequently as building and deploying takes more than a single click or command, then there's still room for improvement. Since it's ran so often, make sure that it does not take too long. If theÂ smoke test or the deploy to every single platform takes more than about a minute, leave them out of the fast build, but prepare another single command that can perform the full deployment test.

Tests against unwanted changesÂ will, depending on their scope, have to be done relatively often, too, so you should automate most of them as well. There are several levels of granularity and often corresponding run time.

Unit tests check theÂ behavior of single classes, functions, and sometimes smaller submodules. Those checks occur at theÂ same level as class design, so there is nobody except theÂ developer who knows that design, who can write those tests.

Acceptance and integration tests check larger parts of the application, but usually not the whole thing. Therefore often a developer is needed to make them work, e.g. by mocking the missing parts of the program.

There is much more to be said and written about all the different types of regression tests, but I won't go into details at this point. The important thing is: If you change your code often, you'll want to run most of the tests often. So you'd better automate them and make them fast.

Checking if a code change was successful usually requires checks at the same different levels, and usually you need to run them more than once, especially if the requirements you implement are nontrivial.

So guess what? You'd better automate them. Doing so has the added benefit that you can add them to the regression test suites once your feature is done. Done as in compiled, tested and approved by QA.

Code quality can be checked automatically as well, although tools like static analyzers etc.Â should not be the definitive last instance to tell you whether your code has good or bad quality. Code quality can be subjective, andÂ not everything can be done y a tool, so you'd better have someone review your code, either by doing pair programming or as a code reviewÂ as part of your process.

Q: Should I really automate everything?

Well, almost. You can't automate everything, because for example exploratory testing is a highly intuitive process that can't be done by machines. Other tests may be very time consuming to automate, e.g.Â because the test objects do not match the test tools available.

However, automatic tests are not only reproducible and thus more reliable than manual tests. If done right, they can be triggered semi-automatically or even automatically, e.g. by a code check in. That way all that is needed is a computer to run them and precious manpower is saved. The net result is thatÂ tests areÂ run even more often, which in turn leads to earlier finding of bugs and more reliable software.

Bottom Line: Automate any test that technically can be automated, as long as setting up theÂ automation costs less than the accumulated effort of manual testing. Strive to design your code and architecture in a way that facilitates test automation.

When everything is automated, why have human testers at all?

Firstly, as written above, a human tester has another view on the functional requirements than a developer, so especially acceptance tests benefit from a cooperation of testers and developers.

Secondly, there always will be things that have not been considered before, so there will be corners not covered by automatic tests.Â Someone has to pokeÂ around inÂ the software, trying to find those blind spots, which is also known as exploratory testing.

Conclusion for developers

Every developer should have some professional pride. That pride demands that we strive for perfection, which in turn means that we want to deliver perfect, flawless software. We will never get there, (hence the need for QA as a last isntance) but our aim as professionals should be to come as close asÂ we can.

And we definitely come closer if we test our code as thoroughly as possible, so testing, and especially writing automated tests, is not some inferior task that should be avoided. It's a central part of our job.

The software development filter bubble

Arne Mertz — Mon, 04 Sep 2017 19:24:16 +0000

Everybody is talking about the filter bubble in social media these days. A similar effect can be seen in developer circles.

In its core, the filter bubble effect is about our desire to be acknowledged. We like to read when others share our beliefs and dislike it when they contradict us. Social networks allow us to select what we read and enable us to filter out the things we don't like to hear. Follow/befriend the people that share our beliefs and unfollow those that don't, and we live in an online world where everything is nice and as we want it.

In software development, things can be quite similar. For example, if you work in web development and are used to deal with JavaScript and its host of frameworks, that's just how it has to be. The world moves fast. You may look with disgust at the developers who work with a dinosaur like C++ or even C and the atrocities they call pointers.

If you are from the other camp like me, and C++ is your home, you may be flabbergasted when you think about how someone in their right mind can use a language that has no static typing and where +[] is 0. I know I had some huge prejudices against JS until I had to work with it a little. (It's not that bad, it's just different).

These examples may be a bit extreme, but there are other ways we build our little bubbles in the dev community. If you are a contractor or consultant like me, you may get some insights into some of those bubbles.

If you read this, you are one of the people who actually does have a look out there beyond their company filter bubble. That probably makes you part of a minority. There are companies and teams where no one or only very few are interested what happens outside in the tech world. For example, I've met a team that used C++ as their only programming language for over a decade, but in 2015 they still did not know that in 2011, a whole new standard with huge changes had come out.

You may think this kind of ignorance can affect only dark matter developers, but that's not true. On the contrary, developers who participate in online communities are likely to disconnect from those who don't.

Those "onliners" are more likely to be hired by companies that have a corresponding culture. I also think that if we are really interested in the current advances in our field, we are less likely to stick too long with a team of "offliners" that don't care as much. Not being able to use those shiny new toys becomes unbearable in the long run.

That effect can make us unaware of that other camp. Like we tend to ignore the supporters of the other political camp, we also happily believe that "almost everyone is using X these days" - forgetting that scores of developers are stuck with an older tech stack or don't even know that there's a newer one.

Don't lock yourself in your bubble. Look beyond your tech stack, maybe even reach out and offer a hand if you have insights that might benefit other fields of development. But be warned, you might learn useful and interesting things! The tech world may be built on ones and zeroes, but it's not black and white.

Refactoring Basics

Arne Mertz — Fri, 01 Sep 2017 08:31:43 +0000

This article was originally published on my personal blog "Simplify C++!". Simplify C++! is a blog about modern C++ and Clean Code.

Rules of engaging your code...

Small compilable steps

Have you ever worked on your code for hours, then you try to compile and test it - and nothing works anymore? Usually, in such a situation you try to fix the problems for a few more hours until you realize that you only got into even more trouble. In the end, you roll back everything and start over, frustrated. Or worse, you roll back and don't even bother to try another time.

That's why refactoring is best done in small steps where each single step compiles and passes the tests. Why pass the tests you may ask. You'll want to pass your tests because to not pass the tests means you changed some behavior. You either accidentally changed something you did not want to change, or you did change it on purpose, in which case you'll also have to change the tests.

Commit often

Every small step on the way is a small victory. Set a rollback point whenever your code compiles, passes the tests and when the change you made contributes to reaching the refactoring goal.

Of course, nobody wants to see a hundred commits consisting of single-line changes. But here is where version control systems like git can help. For example, I often stage a number of small changes vÃa git add before I actually commit something. If a change does not compile or does not have the desired effect, I can simply go back to only staged changes. When I have staged enough changes, I either create a new commit or amend the last commit. Finally, if needed, we're able to squash multiple commits into one.

Have a plan

Plan the small steps ahead. Try to think of a path from the current state of the code to the state you want to reach. Compare what you do to what you planned to do - that way you find out early if you are heading in the wrong direction.

Don't stray from your path. If you find bad variable names, violation of design principles or other things that need fixing, take notes, but don't fix them yet. Finish what you set out to do and fix your findings later. That way your changes stay focused and comprehensible. It also prevents you from being sidetracked and running into time problems. It's of no use if at the end of the day you started a dozen refactorings and finished none of them.

Back and forth

Doing small steps sometimes requires us to do some intermediate steps that have to be undone later. For example, to move a method out of a class we might have to make other members of the class public first. Later, when the method no longer requires access to the members, we can make them private again.

Undoing things we have done a few minutes before might look like a waste of time at first. However, doing it this way gives us some security that we would not have otherwise. Compare it to crossing a pitch black room: It might be safer to feel our way along the wall, the long way round, instead of stumbling through the dark and running into furniture.

The above example also shows something else: We are allowed, sometimes even required to break coding rules during our refactorings. We can violate style guides, duplicate code and commit all kinds of atrocities, as long as our plan includes steps to fix these things.

Don't mix things up

Sometimes you might encounter a problem that prevents you from continuing your current plan. Remember that refactoring means modifying code without changing the behavior of the larger picture. If you need to do such a change to fix your problem, there are basically two options. The first option is to bring the refactoring to an early end (but fixing the rule violations you committed) and apply the change as a next step.

The other option is to roll back the steps you have done so far, fix the problem, and apply the steps again. Rolling back does not necessarily mean throwing away everything. For example, in git, we can check out a point before the refactoring started, fix the problem there on a new branch and then rebase the refactoring onto the fixed branch.

... are more like guidelines.

The points above may seem overly pedantic and tedious. In addition, how small should a small step be? That's up to you. If you are confident that you can do a larger step at once without running into problems, go ahead. If you are refactoring code that is unfamiliar and hard to understand, smaller steps might be appropriate.

The same goes for the number of tests you run after each step. Running a three-minutes test suite after every twenty-seconds change will slow you down terribly. It's a compromise between investing time and sacrificing security. Depending on the size of your steps, even just compiling might be enough, as long as you run all affected tests once in a while.