Monthly Archives: March 2019

Bug Hunting Adventures #13: Prime Sums

“Why, yes; and not exactly that either. The fact is, we have all been a good deal puzzled because the affair is so simple, and yet baffles us altogether.”
― Edgar Allan Poe, The Purloined Letter

Below, you find a little C project that doesn’t do what it’s supposed to do, namely print the sum of the first 10 prime numbers. The program builds cleanly with gcc and clang; that is, without any warnings even when using -Wextra -Wall -pedantic -ansi as compiler options. It’s well-formed and doesn’t crash.

What’s the root cause of this bug? What’s the output of the program? Here are the files, you can also find them on GitHub:

prime_table.h:

prime_table.c:

prime_sum.c:

Makefile:

Solution

People Patterns In Software Development: The Q²S² Framework

“Some people come into our life as a blessing, while others come into our life as a lesson, so love them for who they are instead of judging them for who they are not.”
— Yolanda Hadid

As you know, “People-Patterns in Software Development” (PPSD) is a tongue-in-cheek series in which I present personality traits of software developers and arrange them in patterns. In order to make these patterns easier to compare, I came up with an evaluation framework that I’ve dubbed “Q²S² framework.”

Each letter of the Q²S² (or QQSS) acronym represents one of the four dimensions, along which developers are assessed: Quantity, Quality, Social, and Sharing.

QUANTITY

Quantity captures how prolific a person is. Is an individual a doer who creates or rather somebody who consumes things created by others? Low-producing software developers, even highly educated ones, have difficulties writing code. They overthink, get stuck in analysis-paralysis and have a hard time entering insert mode. But even if they do start, they often don’t sustain and end up failing to make it to the finish line. But getting things done is essential: a bridge over a river is worthless if it ends three meters short of the other bank.

High-volume producers, on the other hand, are totally sold on action, they want to get their hands dirty. If they encounter a Gordian knot, they simply cut it. Without knowing the details, they start with a “shitty first draft” and shape it into the final product. To them, software development is like pottery making: they begin with a lump of clay and turn it slowly but steadily into a vase—and then proceed to make another one, and another one. Whether these vases are of decent quality is a completely different story.

QUALITY

According to a popular definition, quality is the degree to which something meets or exceeds the expectations of its customers. While a certain amount of quantity is essential, it’s by no means sufficient. Quality-oriented developers create software that performs well, is easy to use, and has a low defect rate.

There is a type of quality that is not visible to the customer called internal quality. High internal quality means that the software is easy to comprehend and extend by maintenance developers, and thus supports the incorporation of future requirements. Low internal quality means that the code is hard to maintain, that it is full of technical debt. So much technical debt, in fact, that over time—due to compound interest—the maintenance costs becomes so high that a software company is forced to declare bankruptcy, literally, sometimes. High internal quality, by contrast, denotes investment protection and is the foundation of long-term business success.

Since internal quality is so frequently neglected, I stress its importance a lot. Still, for the sake of simplicity, I decided to merge external and internal quality into a single “quality” dimension. Therefore, a developer with a high-quality rating in the Q²S² framework pays utmost attention to both external and internal quality.

SOCIAL

Even a super-productive, high-quality programmer is still only able to achieve so much in a day. The best carpenter in the world may build you the finest log cabin, yet he’s unable to build a skyscraper, let alone a city. By the same token, some of today’s software products are so large and demanding, it’s imperative that their construction is distributed over many shoulders. To achieve great products, people from different disciplines and backgrounds have to work together smoothly.

The biggest challenges a large software project faces these days are sociological in nature, not technological. Hence, the ability to effectively interact with other individuals is a crucial skill for every software developer. This includes being able to communicate clearly, present ideas in a comprehensible way, give and take criticism, and the willingness to compromise.

SHARING

It goes without saying that productive, high-quality developers are a blessing for every company. But developers who are willing and able to share their knowledge with coworkers can lift them to new heights and thus boost the productivity of the whole team. Like Robert Noyce, co-founder of Intel said: “Knowledge is power. Knowledge shared is power multiplied.” Imagine the benefits if all software developers followed the “each one teach one” maxim.

Developers with a great sharing attitude introduce new tools and techniques, host coderetreats, write blogs, and give one-on-one advice. What is important, however, is that this is done on top of their daily work as above-average-quantity, above-average-quality developers. All knowledge sharing must be founded on and validated by practical, real-world experience. Beware wannabe experts who only teach because they can’t do or don’t want to do what they were once hired for.

CONCLUSION

All four dimensions of this framework are all about the product. Quantity and quality are about the individual programmer’s direct influence on the product, while social and sharing are indirect: it’s the individual programmer’s influence on the influence of other programmers on the product.

You may wonder why there are no dimensions for intelligence, experience, and knowledge. Even though most job interviews put a lot of emphasis on these attributes, to me, by themselves, they are pretty meaningless. At best, such attributes can be viewed as necessary but insufficient. All that matters in the end is the product. Or, to put it another way: “It’s the product”, stupid!”

From now on, I will include Q²S² ratings in all people-patterns. Every dimension has a rating, ranging from one to five, just like is the case for most star-based classification systems that are in use today:

1: Far below average
2: Below average
3: Average
4: Above average
5: Far above average

Thus, a 4/3/5/2 rating describes a developer that produces at an above average rate with average quality, has extremely good social skills but is poor at teaching.

For the sake of completeness, I’ve also added ratings to the patterns presented so far:

Codenator: 5/3/1/1
Statler/Waldorf: 2/2/2/1
Programming Hipster: 4/4/2/2