"The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times." — Robert C. Martin

I'm afraid I have to disagree with this statement. Let me tell you why.

There seem to be many opinions surrounding clean code. Some people have an entire architecture of how code should look. Others stick to the actual layout of the code, or length of a class while even others vaguely point towards Robert C. Martin's books.

One thing is clear; it's something that's really on a lot of developers mind. Clean code makes projects more comfortable to work with and improves shelf life. It's the antagonist of vile legacy codebases that are unmaintainable.

Then why does business always treat it as a secondary objective? Do they just don't get it?

Clean code and architecture indeed allow businesses to have a more maintainable product. But I'm sure you would agree that before you can have a maintainable product, you should first strive to have an actual product.

The foundations of a product are undoubtedly essential; they dictate the mindset of the months/years to come, but they also take a tremendous amount of time. Time in which the project isn't moving. If the project isn't moving, we are not generating revenue. Every start indeed requires a startup cost, but we also need the lights burning and the espresso flowing.

This entire mindset was partly the start of the agile movement. Build a minimal viable product, get it to the market fast; see if there is a demand, iterate.

It's where that horrible motto from Facebook comes from: "move fast and break things".

It seems we've come to an impasse: the tech side wants a well balanced and nutritional dinner, while the business side wants fast food

So yes, that mindset results in those paymentsService god classes that are 5000 lines long and nobody dares to touch. Controllers that speak directly to databases; in short, technical debt.

It seems we've come to an impasse: the tech side wants a well balanced and nutritional dinner, while the business side wants fast food. But it's essential to realise that it's not a tug of war. It's better to look at it as a process that needs some leniency from both sides.

As said in the previous chapter, you can't build a product in a vacuum. You need to stave it against the market. Otherwise, you risk much capital against untested ideas. Investing a third of your budget before you even can think of a front-end might be a bit risky from a business standpoint.

On the other side, keeping acquiring technical debt is also not a way forward. You will indeed have a quick start. Implement features in days instead of weeks. ... till you can't anymore. Just like financial debt, technical debt will eventually catch up with you. And it can end your business just as quickly. It's great to have a product that's a perfect market fit, but if you can't keep up with your competitors cause your application is too slow, or features can't be implemented quickly enough due to the technical mess, you will lose out.

So treat that technical debt as you would financial debt. Use it to invest it into your project. But keep track of it and pay it off. I would recommend this post from Mathias Verraes on how you can do this.

Image courtesy of XKCD (https://xkcd.com/844/)

You also have to keep the scope of the project in mind. Some people build systems with the mindset that it might blow up anytime and we're going to need to support this for years to come. Other people start big projects without tests and pretend that they're going to write them in the future, "when there is time".

It's critical to strike a decent balance here and reevaluate the scope and market position of the product at regular intervals. This evaluation should not be only on the business or technical side; this is a team effort and should also be communicated that way.

It's essential to realise what you are building and the impact it will have in the near and far future. Keep the short time roadmap concise and don't over-invest (financially and technically) but also don't try and outrun the liabilities you are taking on along the way.

Keep communication of the status and impact of the project open towards the entire team, and reevaluate these values on a regular timeframe. Adapt your level of technical investment according to these projections.

Clean code makes projects more comfortable to work with and improves shelf life. Its the antagonist of vile legacy codebases that are unmaintainable. Then why do we see it all the time?

Claiming that sounds pretty snobbish right? I realise that this might come off as something out of a trashy magazine, but I genuinely believe this. So let me tell you what this is about;

So let's start with the vital question; why are admin panels a thing? Well, most products have them so non-technical people can quickly add data in the database and/or easily run tasks — the things developers would typically use console commands for.

These panels are often an afterthought, as a customer won't able to access these. Being an afterthought, this often results in the worst UX possible, enormous navigation trees, and a lack of decent CSS (I've even seen products with admin panels that have no CSS at all.)

Well, to me it's a bit strange. You build an entire portal to your database, the most vital part of your product, that is often used by non-technical people and put close to no thought into it?

Even if only people use it that is fully aware of the data model and structure of your application, this still sounds extremely risky. I would even argue that if your admin panel doesn't support validation on your input, you would be better off with just half a day of SQL training for the people that would use the panel (with protective rules on the accounts). That way, you have a security vector less and don't have to maintain the panel at all.

But it goes further than that. There is this movement in developer land that talks about DX. DX is developer experience and revolves around creating an environment that a developer likes to work in. I'm not talking about ping-pong tables or free sodas. I'm talking about the nitty-gritty itself. Working with a nice API or changing the font of your code editor (IBM Plex Mono <3).

If your entire day is based around working with a webpage, with scarcely any CSS, and upon submitting your form, you see a 500 Error because you made a small typo: that's pretty frustrating. Even if you only have to do a small change every x days, it's still not going to be pleasant.

There is also the point of the broken windows theory. I've written an article about this in the past, but I quickly want to touch upon it here as well. Once you create a part of your application that you don't care about, that's when the entire application starts to slip. These small blemishes never seem to be contained to their "admin panel sandbox."

Things Laravel Made Me Believe - Jeffrey Way - Laracon EU 2015

There is this excellent talk from Jeffrey Way that talks about this concept more deeply. (Now whatever you think about Jeffrey, Laravel or even PHP. I do believe that all of these transients beyond that)

Wasn't your previous post about the ROI of code? 

Yes. In that post, I talked about: time to market, ROI of clean code and how you, as a startup, have to do things quick and dirty to get the ball rolling. Your first instinct might be to see this as a total contradiction to that (so was mine, that's why I wrote this part).

But there are some differences here. When I talk about a quick and dirty hack to meet a deadline, I don't talk about laziness. This point is crucial to me. If you can't figure out how to do something "cleanly" and resort to writing it in the ugly way to reach the deadline, those things are excusable. If you make a form in an admin panel and can't be bothered to add validation to that form, that is laziness. The laziness can poison your database with corrupt data and could have been avoided by putting in 5 minutes of work.

What is the least amount of effort I can do? 

Just use something off the shelf. Open source or not doesn't matter. If you have to validate a credit card number, and your framework doesn't have a built-in validation for that, your first reaction is probably checking Github. So why not for admin panels? They mostly already come with a theme, so you don't have to bother with that. Validation often comes out of the box and as a bonus: it probably also has a ton of extra feature that you might not have thought about. I'm thinking about graphs and user management.

I assume your application already has a way to display tables and forms (or it's going to have it at one point) if that's the case, then you have all the tools already available to display and handle data. Now apply the same care you put into the client-facing part to the admin part.

Regarding the navigation; you can apply the same domain borders to the navigation. Takes a bit more thought, but it's also not going to make you embarrassed at the next standup.

I understand that all of this doesn't sound very critical to the operations of your product. But I do believe that this is all about mindset. A mindset that directly relates to the rest of the application. So next time you have to add a small form to a neglected admin panel, please take the extra 5 minutes and add at least form validation, or maybe even a lick of CSS.

One of the first things I do when I join a new project is checking out the admin panel, that's even before I see a single line of code. Why? It tells us so much about the company and the mindset of the project.

What your admin panel tells us about your company

I always find it amazing to see how different people create pull requests. Some people like to put every file they’ve touched into one big commit. Other people split their commits upper file. There are even people that split it up according to domains.

I’ve been all these people at one point in my career, but these days I’m all into atomic commits. Ever heard of that concept? No worries, let me introduce you to:

Atomic commits, sometimes also called micro commits, is the practice of explaining your thought process in the form of commit messages and code. It comes down to documenting the way to the solution.

An example is the easiest way to demo this.

atomicCommit.js

As you can see, pretty simple stuff: we get all the news items for the database and return some kind of view with the items.

Can you guess what happened to that file when you take a quick look at these commit messages:

That’s all pretty clear right. But you might still be wondering why we created those empty tests stubs first. This is what happens when we click those ...’s

This is the basic idea behind atomic commits: Small commits that tell a story.

The best way to do this by making the commits along with the coding of the feature. Look at a piece of code you have to write or refactor. You will start to see the things you need to do: first I have to create a file. Ok create the file, commit the file and explain why you need that file. Next, I need to create a method, create an empty method, commit. etc...

Yes, it is. I’m not going to lie to you, this is something you will have to actively do. But I assure you it will improve your workflow.

Atomic commits will drive the quality of your code reviews on pull requests way up. they will also understand your thought process, helping them to review the changes you made and keeping them motivated along the way.

I bet you’re not very stoked to start a review on this one:

This is not a very fun thing to do, you will also not get a lot of great insights on this. People doze off or lose track halfway through the review.

Not only will you get better code reviews, but you will also increase knowledge sharing inside the company along the way. If there are junior developers in the team, this can be a great tool to passively teach them some tips and tricks and even change their mindset on code.

They can fully see the workflow and thought process the committer made. And because a single commit is now a much smaller block of code everyone in the team can chime in and discuss the code.

This technique also has the great benefit of making cherry-picking in GIT easier. Mostly because you always have very small units to work with.

Atomic commits are not a new thing, they are even often described as a GIT best practice. Yet I don’t actually see them that often. People often either cite that it’s too much work (an excuse that seems to pop up on every good code practice thing), or that it will make their main branch too verbose (you can always GIT squash your commits before merging).

That said, I really hope you give this a shot. It might make your life and that of your team a little bit better. If not, you just have a feature that is a bit more verbose in your GIT history.

These days I’m all into atomic commits and it really made my work beter. Never heard of that concept? No worries, let me introduce you to it

A few weeks ago I attended a DDDBelgium meetup where I was lucky to participate in a refactor workshop lead by Pim and Joop. After the incredible workshop Pim, Dries and I were discussing some code that we refactored earlier. Not so long in the conversation the words "Integration Operation Segregation Principle" casually got dropped by Pim.

Now I'm going, to be honest with you (as I was with them), I had no idea what the hell he was talking about. And maybe neither do you.

ISOP1.php

As you can see, we have a small piece of code that calculates the price for a few days of rental.

The code itself is pretty straightforward. We gather the start date, the end date. We calculate the number of days and later on multiply those days by the price + the km's driven. A small piece of code, that does a lot.

ISOP2.php

It mocks a few things, then calls the calculator and asserts the results. All in all a very simple unit test, but not a fun one to write.

If we take a look at that PriceCalculator class you can see it structurally does 2 things: it fetches data and performs actions on that data. Or in other words: it integrates and operates.

At this point, you probably already figured out when the Integration Operation Segregation Principle is all about: splitting these up. Let me show what the previous class looks like with this principle applied:

ISOP3.php

ISOP4.php

ISOP5.php

ISOP6.php

"Frederick you devious hack!" you might shout, You've turned a small method into a 4 class method that more than doubles the lines of code.

Well, you're not wrong. It's way more code. And on first glance, it looks way more complex. But let's take a step back and go over it.

if you strip away the dependency injection etc, you're left with

ISOP7.php

There is nothing complex going on here. Everything perfectly describes what is happening. That $dayPrice? Oh, it's been calculated, how is it being calculated? Who cares. No need to worry about it. Someone with almost no programming knowledge can read this method and fully understand what's happening here.

ISOP8.php

I would argue that the logic in there is even more simple.

In the future, there might be some business logic changes (we might need to do something with tax?). We now know where we can do that, everything is contained in this little class.

This is also a nice illustration of the Open–closed principle.

So yes, we do have a lot more code. But it's all very simple code, easy to read, easy to debug and the coolest of all: Easy to test.

ISOP9.php

Now that is a nice unit test. No mocks, easy to write, easy to read. (compare this to the unit test at the top of this article).

As you can see the Integration Operation Segregation Principle is just a long and complicated term to describe something very simple. This all might seem like a lot of work, but it's worth it. Your code and especially your tests will thank you later

If you want to read more about this, do check out this incredible blog post: The Incremental Architect´s Napkin - #7 - Nest flows to scale functional design

Not so long in a conversation the words “Integration Operation Segregation Principle” casually got dropped by Pim. What the hell is IOSP?

The integration operation segregation principle

I work in many legacy codebases, and in fact, I’ve made it a big part of my career. I love diving into big monoliths that have grown out of proportion and tidying them up. One of the best parts of that work is rewriting a God class into a collection of small reusable classes. Let’s take a look at what makes a simple class great.

One of my favourite types of classes is a value object. For those not in the known, a value object is a small class that holds a value with a tiny bit of extra logic surrounding it. Sounds simple enough right? I think a nice way of looking at these classes is implementing them as an extension of the type system of your programming language. Let take a look at an uncomplicated example.

VO1.php

This small class doesn’t do anything really, and it just holds two strings. The only tiny bit of function (at first glance) is that it concatenates the two strings. However, for the minimal amount of code in this class, it does offer a ton of value to your codebase.

Once we start replacing every occurrence of the first name and last name with this simple class, you will quickly begin to see the value. First of all, every time you come across this class in your code, you know that it has a first name and the last name in it. You also know that both of these values will be strings. And that you have an easy way to display the first name - last name combination.

You can now also add this as a safety in your new classes. You could, for example, do something like this:

VO2.php

Here you easily guard your method from all kinds of extra logic. You know that the variables that enter the method are of the type Email and Customer class.

There is however still a major issue with our values objects. We could still trick our system into accepting empty strings. Let’s take a look at how we can make these classes just a tiny bit more robust.

We know that our values in our object will always be of the typed string, but “” is also a string. so you could do

new CustomerName('', ''); or even new CustomerName('\$', '!');

You could allow that last one if you are building a platform for rappers, but in most cases, you would want to guard against that.

If you are using PHP (like the examples are), I would suggest using a package like webmozart/assert.

VO3.php

(you could add a private validation method to the class that is called on the first line of the constructor if there are many validation rules)

The class is now a lot smarter; it validates the values that come in and will throw an exception when they don’t meet the expectations of the class.

Now you can be sure that whenever you encounter this class, the values within will be usable.

Adding more means of production to the classes 

It might be very tempting to start now adding more and more logic to these classes. However, I would caution restraint here.

A common thing you see is people adding getters and setters to these classes. You might notice we already have getters (we just not named them getters), and I would strongly recommend against adding setters.

If you need to update a value in the class, create a new instance of the class. Value objects are meant to be built and discarded. By creating new value objects you also make sure you pass the constructor every time, and therefore including the validation.

If you really feel like adding setters, make sure they create new instances themselves:

VO4.php

Another thing to touch upon is named constructors. A named constructor allows you to create the value object under different circumstances. I feel like it is easiest to explain with another example.

VO5.php

(this example is to demonstrate the function of a named constructor. This method assumes that a name is always in 2 pieces with the first name as the first piece. If you want to implement this, please add extra logic)

These constructors are a small convenient way to create the value object. Named constructors allow for great flexibility. However, like always, you should not take this flexibility too far.

You should always ask yourself, is this method solving a real problem, or am I just adding this for a one-off small convenience?

Named constructors are very useful in a “Time” class, where you can create the class from a string format, or from the hour, minute and second parameters as further explained here by Mathias Verraes.

There is still a lot to be said about value objects. We haven’t touched upon testing, logging, naming…

For more information about these topics, I would advise you to look into some DDD books or even better check out Matthias Noback’s book “Style Guide for Object Design”. A book that prompted me to write this article. (I get no personal benefits for advertising this book, I just think it’s a great book)

If you haven’t implemented Value objects into your codebase, I would greatly advise you to give it a try. You will wonder how you ever lived without it.

A value object is a small class that holds a value with a tiny bit of extra logic surrounding it. Sounds simple enough right?

As you might know, I co-organised a PHP meetup called: PHP Antwerp. Some time ago we had one of our talented speakers: Joeri Sebrechts talk about “What every developer should know about time, no excuses“ (If you ever have the chance to see it, I wholly recommend it). In this talk, he mentions briefly the Y2k38 problem. A bug that will wreak havoc on systems that store time in Unix epoch timestamps.

For those of you who weren't fully sentient around the time, everyone partied like it was 1999 (for the second time). The big problem around that period was the Y2K bug. Quickly summed up, the Y2K bug was due to people storing years in a 2 digit form like 88 or 67. Now when the year ticks over to 2000 (or every 100 years) they would reset to 00 or 01.

At the time there was a lot of media buzz around the topic. Planes would fall out of the sky, hospitals would shut down, society would collapse. When the clock eventually ticked over to the new millennium, everything seemed to be still fully functional (including the bleached spiked hairstyles). The media quickly resumed the new hot topic and it all quickly died down. The entire event would be remembered as a hoax.

But it absolutely wasn’t. In Gary Hockin’s talk “Using Open Source for Fun and Profit” (One of the best talks I’ve ever seen) he briefly talks about working together with other engineers to check applications for the bug and mitigating the issue (yes he is that old). The truth is that it cost a lot of hands and a lot of capital to sort out.

And even then we didn’t make it out without a scrap. Credit card machines stopped working, 2 unplanned abortions ensued, An alarm sounded in a nuclear powerplant in Japan and even the US Naval Observatory was touched.

So yeah, Y2K happened because of a logical problem, but 2038 sounds a bit random… That’s because we are looking at the date in a “human-readable” form. If we store the data as a Unix epoch timestamp, a form of timekeeping that counts seconds forth from 00:00:00 1 January 1970, we would get 2147483648.

Again, for some people, this might still look like a very random number, but that is more than half of the maximum range an integer can take on a 32-bit system. An integer has a positive range and a negative range. This allowed us to go to dates before the year 1970. Half of its range is negative and half of its range is positive. If you count these two halves up, you might see that we are dealing here with an integer overflow. More precisely after 03:14:07 UTC on 19 January 2038.

It is possible to change the positive and negative range of the data. However you can not extend it, but you can shift it forward or backwards. For example, a company that deals a lot in old data might have shifted the timestamp further back. Giving it less reach in times after 1970.

This means that the Y2k38 might not appear for everyone at the same time. Or even in the year 2038.

Mostly the same situation as Y2K, but in this case, we don’t go back to 1900 but we go back to 13 December 1901. The good news here is that we jump from a Tuesday to a Friday. The bad news is that banks might calculate negative interests, airports might send wrong routes to planes, basically, everything that has a critical function related to timekeeping might be in trouble.

When we look back at the Y2K bug, it all seems kinda silly. Why would you store a year in a 2 digit form … why couldn’t you anticipate this issue … The same question arises for Y2k38, you know the integer will someday run out in your 32-bit system. So why use it?

There is a bit of survivorship bias going on here. Take for example the project you are currently working on. It can be a long term legacy project, a cool new startup idea or a small advertising project. Will that be around for 5 years? 10 years? 30 years? It’s very hard to tell right now, technologies change, the product changes. Preparing your code for an issue that might show up in 30 years sounds irrational. Yet somehow some systems keep running without that refactor for years.

premature optimization is the root of all evil (or at least most of it) in programming. - Donald Knuth

What software is at risk at the moment? 

It is very fussy to give a full list of all systems at risk. But it is safe to assume that almost all systems that count on Unix timestamps in a 32-bit environment will be at risk.

This includes operating systems, databases, embedded systems …

Should I start digging a fallout shelter? 

Yes, yes you should. Would be a kick-ass ice breaker. “Did you know I have a fallout shelter”? Actually, scrap that, sounds kinda creepy. You would at least not need one for this bug. Just as with the Y2K bug, this one will pass. There will be a lot of money spend. A lot of people will earn a lot of money. But in the end, it will mostly be resolved.

In the meantime, it seems best to not store your dates in Unix timestamps if you're on a 32-bit system. For all, you know your software might still run on some old machine in 20 years.

In 2038 a bug that will apear that might trigger a strong feeling of déjàvu to the Y2k craze. The Y2k38 bug seems to come at a very random moment, but it all makes sense if we apply a bit of computer science to it.

The y2k38 bug: the biggest news craze of the year 2038

Why is it that most legacy software projects are not really fun to work on? How can we stop that greenfield project to turn into one of those dull big projects? I would argue that it’s all in the foundation.

In 1982 James Q. Wilson and George L. Kelling wrote an article on a theory they had. It stated that once there is a building in a neighbourhood that shows small signs of neglect (a mailbox that’s overflowing with a few days worth of mail, trash on the street, a broken window that stays broken, ...) the entire neighbourhood devalues and opens itself up for more neglect.

People tend to care less about something that has a lower perceived value.

Small neglects can quickly damage the perceived value of the bigger system they are part of.

Now please note, this is as the name suggests, just a theory. And a highly criticised one at that! The theory is often criticised for promoting stigmatisation and “zero tolerance” attitudes.

Now I’m not really big on sociology, so I’m not going to give personal insights into how the broken windows theory might work in a social or political environment. But we can try and see if we can maybe link some of its ideas to software projects.

Let’s first start with looking at a piece of code. I’m going to take a piece of code from an open-source project (In this case the Slim framework build in PHP made by Josh Lockhart)

brokenwindowSmall.php

This is the resolve method from the CallableResolver class

Now it doesn’t really matter what the code does, but we can roughly see what is happening here. The code might not be perfect, you might even have seen something you would do in another way. But the ideas are quickly shown.

brokenWindowSmall2.php

This is functionally the same method, so it does the same thing. I’ve just removed a few good practices like the early return and some PSR rules. As you can see this code is a lot harder to understand.

I know most people don’t write code like that, and this is probably a bit over dramatised. You would not want the developer that wrote code like that in your team. But still, I would bet you have seen code like this before. Maybe even in a codebase, you work in.

If we apply the broken window theory to this code, we could argue that it all started with a small bit of neglect. Maybe it was Friday afternoon, we’ve sent the original code in and a colleague commented that it misses a small use case. So we’ve quickly added it in, but forgot a bit of formatting. “Whatever, It’s Friday and I have a paper aeroplane folding competition to attend! I’ll do it next week.”

You might think you or a colleague of yours will probably see this and fix it Monday morning. But let’s be real here. That part of code will not only not get fixed, but it will also probably get worst.

How can we prevent this from happening? 

The best way to keep these issues from appearing is to never let them in the codebase in the first place. It is mostly a mental thing.

For the people who’ve never been in the “Boy Scouts of America”. Statistically, quite a lot of people. They supposedly have a rule (I didn’t actually found the rule, but that might be because I only know about boy scouts from Wes Anderson movies):

Always leave the campground cleaner than you found it. If you find a mess on the ground, clean it up regardless of who might have made the mess.

Robert C. Martin, whom you might know better as Uncle Bob, argues in his book Clean Code that we could perfectly apply this mentality to programming. So every file you open, try and leave it a bit better than you’ve found it.

I would however suggest you do this in a separate branch/PR. What can get a bit tedious?

Of course, you write tests (not writing tests in 2017 is like using bronzer for contouring in your make-up). So you probably already have a build server in your stack. Now luckily for us, we can automate the code style, and run “tests” against it in much the same way. With the added bonus of not having to write any kind of “style tests”.

Scrutinizer is a popular one. It gives the option to assign a score to both the individual files and the entire project. The score is calculated on the rules you assign for your project (it ships with a standard ruleset). If your commit sinks the score, it’s time to refactor.

Some alternatives like Codacy and Sideci even allow for the option to automatically add comments to a pull request. So it feels like a human is giving actual code reviews. This can be very handy for one person teams. (Note however that this is nowhere as good a real review from an actual colleague, at least not for now).

Now if you want to go 1 step further, there is this cool tool called Grumphp. Grumphp hooks into your Git commit hook and runs its test before commit. If the tests fail, you can’t commit. As a picture says more than a thousand words; check out this cool GIF I stole from their Github page:

As you know, you can’t have an insightful blog post without at least one mention of Jason Fried. In one of his posts, Jason talks about how they work at Basecamp. Most of the article goes beyond the scope of this post (still a great read), but what really struck out for me was this part:

Once a six-week cycle is over, we take one or two weeks off of scheduled projects so everyone can roam independently, fix stuff up, pick up some pet projects we’ve wanted to do, and generally wind down prior to starting the next six-week cycle. Ample time for context switching. We also use this time to firm up ideas that we’ll be tackling next cycle. More on this in a bit.

This is probably a hard sell to make to clients or your boss. But even if you could get to a “work 6 weeks on features do 2 weeks cleanup”, you could end up with a much cleaner and more workable project. Those practices allow for faster implementation of new features and most important of all: Happy developers.

I truly believe that the broken window theory can be applied to software projects. In my personal experiences, I’ve rarely seen a project start out as a total mess. If it ended up as a mess, it was gradually. I also believe that this is not necessarily the fault of developers working on the project, think of it more as frogs in a pot with gradually increased temperature of the water. One morning you just wake up and take a look at the project and realise that it has gotten really messy.

I think that the best way to counter these small neglects sneaking up in your codebase is by really analysing every pull request. Be it by manual code reviews from peers or by dedicated automated tools. In the best case both.

Another important thing to note is that senior developers are in no way immune to these mishaps. Skill level has in my opinion less to do with this kind of stuff. Everyone can have an off day, it is just important that these off days don't stick around in the project.

The broken windows theory or “why some projects are just destined to suck

Frederick Vanbrabant's

delirious rantings

The economics of clean code

What your admin panel tells us about your company

Atomic commits: telling stories with git

The integration operation segregation principle

The simple class

The y2k38 bug: the biggest news craze of the year 2038

The broken windows theory or “why some projects are just destined to suck