Iván Stepaniuk's Technical Blog

There Are Only Three Types of Bug

Thu, 07 Oct 2021 00:00:00 -0500

As soon as there is code, there will be bugs. Gojko Adzic said in a keynote in the Agile Testing Days in Berlin, almost a decade ago;

… It’s called an issue tracker because when you have one, then you have an issue.

The traditional bug or “issue tracking” processes have advantages on waterfall engineering processes, but they have very little to do with an agile development environment. We don’t need to document past bugs to avoid them in the future, we don’t build knowledge bases of defects; we have unit tests that prevent regression.

1. Urgent bugs

Bugs that are so urgent as to stop whatever you are working on and start fixing it.

2. Important bugs

Bugs that will have the top priority as to what to work on NEXT; they are at the top of your TODO list.

3. Bugs that you will NOT fix

This defect is not urgent nor important as per the previous definitions and likely has been there for some time. If it’s not important enough to be considered of type 2. then there is no need to keep this on any backlog or issue tracker. Close it or delete it. Adios.

Is it’s a bug or a feature?

There is no “type 4”. If fixing a bug is not important enough to be of type 2. it’s unlikely that it will have priority over anything else in your backlog anyway. If it really does, by all means go ahead and treat the bug as any other story, subject to the same priorities, refinement and estimation process (if you do that), and of course the same definition of done. But for example, if you are doing Scrum and you wouldn’t tackle this bug on your next sprint either, then I’m afraid it was of type 3.

Sentinel Values Considered Harmful

Wed, 22 Sep 2021 00:00:00 -0500

TL;DR:

Sentinel values and other kinds of “flag” values have no place in modern languages, use types!

A bit longer:

In languages like C, it is common to use sentinel values, sometimes also called flag value, signal value, etc., as a way to interrupt a loop. It is also common to return negative values as a way to indicate an error condition where positive values indicate that things went well.

int find(int buffer[], size_t len, int value)
{
    for (int i = 0; i < len; i++) {
        if (buffer[i] == value) {
            return i;
        }
    }
            
    return -1; // not found!
}

This makes a lot of sense in C or even straight assembler; the CPU can very quickly determine whether a value is positive and branch conditionally.

You will find similar APIs in modern languages as well, such as Python’s find(), that keep the tradition alive:

"an apple, a pear and a banana".find("orange")  // -1

However, when writing your own code in a typed language, this is just an anti-pattern, and a clear indication that you are using primitives where you should not.

So for example in Java, instead of doing:

public int findCustomerIdByUsername(Username username) {
    for (Customer customer : this.customers) {
        if (customer.getUsername().equals(username)) {
            return customer.getId();
        }
    }
    
    return -1;
}

Consider the much safer:

public CustomerId findCustomerIdByUsername(Username username) {
    for (Customer customer : this.customers) {
        if (customer.getUsername().equals(username)) {
            return customer.getId();
        }
    }
    
    return new NullCustomerId();
}

In this case, using a null object pattern (but a throw new CustomerNotFoundException() might be the best choice in some circumstances).

Extract Test Fixtures Early

Fri, 10 Sep 2021 00:00:00 -0500

TL;DR:

When writing unit tests, extract test fixtures early on.

A bit longer:

We often delay some types of refactoring with good reason. During a TDD session, an extract class, or even extract method done too early might limit your refactoring chances later, so we sometimes let refactors “ripe”.

However, the construction of the objects involved in unit tests is better elsewhere and not on the tests themselves, as soon as possible.

The reason is that there is no amount of automatic refactoring that will let you easily change the signature of your Value Objects if they are repeated over and over in every related unit test.

So instead of doing:

@Test
public void it_publishes_an_ugraded_event_when_a_regular_tenant_switches_to_premium() {
    var premiumPlan = new Plan('example premium plan', PlanType.PREMIUM);

    tenant.switchToPlan(premiumPlan);

    verify(mockEventPublisher, only()).publish(any(AccountPlanUpgraded.class));
}

@Test
public void it_publishes_a_downgraded_event_when_a_regular_tenant_switches_to_a_free_plan() {
    var freePlan = new Plan('example free plan', PlanType.FREE);

    tenant.switchToPlan(freePlan);

    verify(mockEventPublisher, only()).publish(any(AccountPlanDowngraded.class));
}

// and many more ... 

Try to introduce fixtures early on:

@Test
public void it_publishes_an_ugraded_event_when_a_regular_tenant_switches_to_premium() {
    var premiumPlan = Fixtures.givenAPremiumPlan();

    tenant.switchToPlan(premiumPlan);

    verify(mockEventPublisher, only()).publish(any(AccountPlanUpgraded.class));
}

@Test
public void it_publishes_a_downgraded_event_when_a_regular_tenant_switches_to_a_free_plan() {
    var freePlan = Fixtures.givenAFreePlan();

    tenant.switchToPlan(freePlan);

    verify(mockEventPublisher, only()).publish(any(AccountPlanDowngraded.class));
}

// and many more ... 

Implementation Inheritance Last

Tue, 24 May 2016 00:00:00 -0500

TL;DR:

When designing, consider class composition and delegation BEFORE extending or designing classes for extension. Extension is less reusable and less maintainable. Don’t be very “clever”.

A bit longer:

Implementation inheritance is often not the best pattern to reuse code or make code reusable.

Implementation inheritance breaks encapsulation and forces us to peek at the parent implementation to be able to inherit from it safely, the interface of the base class is not a safe contract to extend on.

Inheritance is the tightest form of code coupling. It is especially dangerous in Ruby when mixed with concerns out of sight, mixins, and the fact that Ruby does not have a ‘final’ or ‘sealed’ mechanism to prevent unsafe inheritance.

More often than not, it is better to compose or delegate rather to extend, especially when there is no clear and orthodox inheritance pattern (template method, strategy, etc.) It is often impossible to get inheritance right when adding features to existing code that does not follow OCP, not to mention trying to reuse these bits afterwards! Impossible.

Composition is normally accomplished by DI through the constructor in the object that needs the behavior. DI in the Ruby world is kind of a controversial thing, mainly because of people misread and missquote @dhh. That aside, let’s just refrain from further designing “clever” inheritance-first designs. Even hardcoding dependencies in a service is a better way! (but you better not http://goo.gl/tLMGGb)

The Shapes of Bad Code, Part 2

Wed, 28 Jan 2015 00:00:00 -0600

I have noticed that when looking at some not-so-awesome piece of code for the first time, I can tell many things about it even before putting my glasses on, and while scrolling at a speed at which it is actually impossible to read anything at all.

This is Part 2, check out Part 1!

The Shape of Bad Code, Part 2

Abuse of vertical spaces

The single-responsibility principle applies at many levels, and it definitely does at a method level. When a method does more than one thing but has not been split in separated methods, it is common to see vertical spaces separating this different functions. If you need to add vertical space to understand the body of a method, wouldn’t it be better to extract that second section as a separated method and give it a good name?

Comment-delimited sections

This is a somewhat improved version of the previous shape. Each section is separated by vertical space, but comments have been added at the start of each section to try to make the reader’s life easier.

Again, more often than not, this sections can be extracted into several methods, and those comments can be transformed into the names of the extracted methods. If there where many sections to extract, it is also probable that these methods actually belong to a new class!

Stay tuned for the last ugly code shapes!

I will never work for you

Fri, 02 Jan 2015 00:00:00 -0600

There are a couple of industry sectors that I would rather not write software for, ever. The most important ones are:

Weapons, Military & Defense
Most Coal, Oil & Gas
Financial Services
High Speed Trading
Investment Banking
Most Adult Entertainment
Casinos & Gambling
Most Health Insurance
Digital Rights Management
Religious Organizations

There are many others, the common denominator being that I do not believe these activities have a positive impact in our society.

Invitation

I make this list public as an invitation to you, software developer, to examine the social and ethical consequences of our professional activity.

It is undeniable that programmers have an increasing impact in our world through the software we write. If our only concern is doing our job right but we not mind about the consequences of what do, we risk becoming mercenaries.

At any point I suggest that my list is universal, different persons have different thresholds and sensibilities. It is nonetheless important that you ask yourself whether you are being consistent with your own values and principles, and perhaps, make your own list.

Dear Recruiter

Wed, 31 Dec 2014 00:00:00 -0600

I am not actively looking for a new job at the moment. Nonetheless, thank you very much for thinking about me for a position, or offering your help with my professional career.

I am always open for new opportunities, and it is always good to keep an eye on our industry’s needs. I receive many requests or proposals like yours every week. Unfortunately, I could not possibly answer them all personally. That is why I have created this page on my site, I hope you do not mind.

Even if I were actively searching for a new challenge, there are a couple of things I need to know upfront, before actually considering it. Because this is non-negotiable, I do not deal with external recruiters, headhunters or employment agencies of any sort. Understandably, they cannot provide this information. I am sorry if that is your case.

The list may seem a bit extensive, but after all, these are basic things I would look for if I was applying for a position myself.

Basic company details

Mission, vision, purpose, market/customers.
The company founders, key people, who they are & what drives them.

Is there a dev team already?

Who are the key team members
What have they done?
What are their team practices and values?

Furthermore, if you are an internal recruiter or HR person and can actually point or link to this essential information, note that there are a couple of industries and markets I rather not write software for, ever. See the list in this post.

Thanks for understanding!

My CV

My LinkedIn profile is complete and updated. You can easily export a PDF from it if you need it. There is also more information about me in this page

Contact me

If you have further questions, you can mail me at istepaniuk@ Google’s well known free email service.

The Shapes of Bad Code, Part 1

Mon, 29 Dec 2014 00:00:00 -0600

– “Oh my god, look at this code!”

The Shape of Bad Code

So what is that I see? The only thing you can see while scrolling that fast and squinting is shapes, the shapes formed by different blocks of text filling the screen, plus the colors of your syntax highlighting.

So I decided to make some screenshots of my text editor to illustrate some of these bad code shapes, and I will write a post for two of these at a time. I also distorted the images to make sure we are not actually reading this code.

Code Duplication

This is probably the best example so it goes first. This is JavaScript, but that is completely irrelevant in this case. This image shows two near-identical functions, both fit the screen and what’s going on is quite obvious. Sometimes a few scroll up & down movements are required to reveal a block of code that has been mercilessly copy-pasted, even more than once. I will not tell you why having duplicated code is bad, you probably learned that the first time you write a program with more than 30 lines.

This duplication was probably introduced because it would have taken 120 more seconds to understand the original functionality and modify the existing code accordingly. Of course, it will now take 10 minutes to revert the damage, or even more if the different copies started to diverge.

Too Many Dependencies

This is Python code, but the same shape is valid for any other language that requires you to declare the dependencies before using them, and that would be most of them.

We do not know what is that this piece of code does, but there is something I can be sure of; There is practically no way that a this file/module/class is doing only one thing.

If it needs this all these import statements, the single responsibility principle is clearly not being observed. If the file/module had many smaller classes with different dependencies each, it’s also time to split this file into smaller ones, as almost every reason to observe SRP in classes and methods also applies for entities at the file (or module, package, assembly, etc.) level.

More ugly code shapes!

Check out Part 2, and also Part 3

Something Is Terribly Wrong with Wordpress

Sun, 28 Dec 2014 00:00:00 -0600

WARNING: This is just a rant, probably you should not read it.

This 2014 was a year of many changes, new company, new country, new house, all excellent excuses to stop writting posts! Lately, for these and other reasons I was not finding a lot of oportunities to write here. To make it even worse, every time I logged into my wordpress admin interface to write a draft or post, I remembered how hard Wordpress sucks. Really.

Some years ago I decided to start blogging and went with Wordpress. It was the obvious choice, popular, and very easy to install and use. The problem is that what you get from Wordpress out of the box is not good enough, at least if you are anywhere close to serious about it.

As soon as you go online the spam will start pouring down. The built-in comment system can drive you crazy when you have 1 real comment for every 5000, but that’s easy, just spend half a day trying plugins until you find the one that does not cost you an eye and actually filters something.

The same goes for social buttons, analytics, your twitter card, ~~google authorship~~,… Plugin magic!. Do you want to add some code snippets to your posts? No problem, 3 or 4 plugins latter you will find something that does not completely destroy the theme or brings the whole server down.

Wordpress releases updates quite often, but many of those installed plugins will start failing with even minor version upgrades, not only because they are hacky (some really are, even the popular ones) but because everything seems to be so tightly coupled to the Wordpress core that they shouldn’t be called plugins but grafts. Good luck trying to keep all those updated. 17 in my case.

All these hacks slow down your site, but don’t worry, there is a cache plugin to solve that! there is even a plugin to make Wordpress secure enough (WTF!) so your hosting provider does not shut you down when some script tries to brute-force your admin credentials, or when spammers bring your site to it’s knees.

Back to square one

With all those hacks, the site can respond reasonably fast for the public, but that doesn’t make the admin interface any faster, specially if you are on a cheap hosting provider. Bet your bottom dollar that any support ticket about Wordpress performance is going to contain “disable all the plugins” in the very first answer.

Questions

Given that:

I have less than 200KB of written content.
I have less than 4MB of pictures.
The site gets an average of 100 daily sessions with only 1.2 views per sessions.
It has very, very ocasional traffic bursts.

Then:

Why do I need all these plugins?
A cache plugin? Why isn’t it just fast enough for this?
A security plugin? Why isn’t it secure enough?
Why is that the built-in comment system is not practical, even for a small site?
Why do I need a full-fledged RDBMS to power a simple blog?

I just want to write some stuff, it shouldn’t be so damn complicated.

The solution

If you are not a developer or sysadmin or you would rather spend your time blogging and not dealing with this nightmare, get somebody to manage your Wordpress for you, or get a paid wordpress.com account, or a ghost.org one, etc. Running it yourself is an incredible waste of time.

If you ARE a developer or sysadmin wanting to run a tech blog, there is a solution! it’s called Jekyll and I will tell about it very soon!

Linux Counter

Sat, 15 Feb 2014 00:00:00 -0600

I just remembered I have one of these, and look! ~~It still works!~~

Soon it’s going to be 15 years since I started using Linux, time flies.

UPDATE:

Well… that didn’t last much longer. The Linux Counter project was shut down in 2018. The last available estimate of Linux users was 91.9 million, as of August 2017.

Iván Stepaniuk's Technical Blog

There Are Only Three Types of Bug

1. Urgent bugs

2. Important bugs

3. Bugs that you will NOT fix

Is it’s a bug or a feature?

Sentinel Values Considered Harmful

TL;DR:

A bit longer:

Extract Test Fixtures Early

TL;DR:

A bit longer:

Implementation Inheritance Last

TL;DR:

A bit longer:

The Shapes of Bad Code, Part 2

The Shape of Bad Code, Part 2

Abuse of vertical spaces

Comment-delimited sections

Stay tuned for the last ugly code shapes!

I will never work for you

Invitation

Dear Recruiter

Basic company details

Is there a dev team already?

Thanks for understanding!

My CV

Contact me

The Shapes of Bad Code, Part 1

– “Oh my god, look at this code!”

The Shape of Bad Code

Code Duplication

Too Many Dependencies

More ugly code shapes!

Something Is Terribly Wrong with Wordpress

WARNING: This is just a rant, probably you should not read it.

Back to square one

Questions

The solution

Linux Counter

UPDATE: