Category Archives: Programming

Deployed To Production Is Not Enough

You have developed a new feature. The code has been reviewed, and all the tests pass. You have just deployed this new feature to production. So on to the next task, right? Wrong. Most of the time, you should check that the feature behaves as expected in production. For a simple feature it may be enough to just try it out. But many features are not easily testable. They may be just one part of a complex flow of actions. Or they deal with external data fed into the system.

In such cases, checking if the feature is working means looking at the logs. Yet another reason for checking the logs is that the feature may be working fine most of the time, but given unanticipated data, it fails. Usually when I deploy something new to production, I follow up by looking at the logs. Often I find surprising behavior or unexpected data.

Continue reading

Good Logging

To check if a program is doing what it should, you can inspect the output from a given input. But as the system grows, you also need logging to help you understand what is happening. Good log messages are crucial when troubleshooting problems. However, many developers don’t log enough information in the right places.

Continue reading

20.5 Years of XP and Agile

In the fall of 1999 I got the biggest productivity boost of my entire career as a software developer. In the October issue of IEEE Computer magazine, there was an article by Kent Beck called “Embracing change with extreme programming”. In it, he outlined Extreme Programming (XP), which includes much of what we now refer to as agile development.

By then, I had been working as a software developer for seven years. The standard development methodology at that time was waterfall: document-heavy year-long projects, frozen requirements, change control boards, manual testing at the end of the project, and so on. Software development succeeded despite the methodology, not because of it. Reading the article was a real eye-opener. I felt it was describing how I naturally worked – in short cycles, with fast feedback, and frequent redesigns.

(And yes, I meant to write this last fall for the 20th anniversary, but I didn’t get around to it then. But hey, better late than never, even if the title has 20.5 in it now)

Continue reading

Secure by Design

I really like Secure by Design. The key idea is that there is a big overlap between secure code and good software design. Code that is strict, clear and focused will be easier to reason about, and will have fewer bugs. This in turn makes it less vulnerable to attacks. This is easy to say, but Secure by Design is full of techniques for how to actually do this. Here are the ideas from the book that I liked the most.

Continue reading

More Good Programming Quotes, Part 4

Here are more good programming quotes I have found since my last post.

Microservices

“Microservices are just dynamic linking over HTTP”
via @mononcqc

“kubernetes – turning things off and on again, at scale”
@decimalator Continue reading

Grokking Deep Learning

In the book club at work, I just finished reading Grokking Deep Learning by Andrew Trask. It is an introduction to deep learning, but there are some problems. It spends a lot of pages on the basics, and in the end moves on to some fairly advanced topics. It is also contains many small and irritating mistakes. However, it does have some great insights into deep learning. Continue reading

Classic Computer Science Problems in Python

I really enjoyed Classic Computer Science Problems in Python by David Kopec. It covers many different problems I hadn’t read detailed explanations of before. For example: neural networks, constraint-satisfaction problems, genetic algorithms and the minimax algorithm. Unlike many other books on algorithms and programming problems, this one builds up complete (but small) programs that are easy to explore on your own.

Continue reading

When TDD Is Not a Good Fit

I like to use Test-Driven Development (TDD) when coding. However, in some circumstances, TDD is more of a hinderance than a help. This happens when how to solve the problem is not clear. Then it is better to first write a solution and evaluate if it solves the problem. Writing tests only makes sense after the solution is viable. Continue reading

Book review: Accelerate

The book Accelerate details the findings of four years of research on how DevOps affects various outcomes, such as software delivery tempo and stability, as well as the organizations’ profitability and market share. DevOps in this context means things like continuous delivery, automated tests, trunk-based development, and proactive monitoring of system health. It is quite clear that DevOps practices bring lots of benefits to organizations adopting them. The research findings are also in line with my own experience of DevOps.

Continue reading

More Good Programming Quotes, Part 3

I like good programming quotes. Here are some new ones I have found since my last posts.

Complexity

“Why do people find DNS so difficult? It’s just cache invalidation and naming things.” – @jdub Continue reading