IT

Lessons from the kitchen timer.

Even if the task looks trivial, sometimes you need a professional.

When developing software, the contractor needs to understand the difficulties and the methodologies, and the client needs to be willing to step out of his “that’s the way we’ve always done it” habit of working with traditional contracts.

When you make a bridge you have a plan. You know exactly how much you have to dig and how much concrete and iron you’ll use. You can ask a contractor how much and how long. If the bridge was software, all you’d know before you started to build it is some vague requirements like “it must have a capacity of 7 thousand vehicles per hour in each direction”. A contractor wouldn’t be able to give you a quote. However, it’s not impossible to make good estimates for software.

“Ten years ago, if I wanted to do a simple computing task, I needed to hire a programmer. Today I do it myself in Excel. It seems unlikely we will be needing any programmers at all in a few more years.”

—My boss, c1995

It’s not just our homes that can benefit from Marie Kondo’s method—it’s also our businesses.

If throwing it away is going to pay off, you should throw it away—the amount of previous money and effort is irrelevant.

“Oh, this thing is so complicated! I’ll just do something simple in Excel.” If you ever said this to yourself, here is the result you got.

It’s an old Greek saying that however bad something is, there’s always a good side to it.

I created a toy application, which, if you were lucky, would cost you 500 or 1000 dollars/euros. Real projects cost much more.

Despite having taken 18 hours of work, it the application needs have some way to go.

A developer will sometimes be able to do wonders in minutes, and sometimes get stuck for hours while trying to change a comma.

A graphic that shows where a programmer spends his time in order to write a simple program.

Search in 1.7 million U.S. transport businesses; the FMCSA census data for humans.

“We paid for it, therefore now it must pay off.” Here’s how to escape that damaging mentality.

If you have your nephew develop software for you, costs will be way smaller. But these savings come at a, well, cost.

All software solutions suck. The thing is to find one that sucks less.

If you are a new business you may think you shouldn’t worry about code quality now, and you’ll do it “later”. This mentality has driven companies out of business.

We often worry a lot about how to proceed with automation. Sometimes we fail to ask: Should we proceed with automation?

Warranties can help, but they are not the answer to the problem of automation.

Many companies get into trouble believing that they can just install the software and throw in some data. Inevitably, the scope of the project grows and what was supposed to be a simple system ends up a confusing mess.

Two stories, one from Truckstop.com and one from Pixar, illustrate an issue that is often overlooked in young companies.

Becoming dependent on an IT system can hinder progress. Not becoming dependent can make an IT project fail.

The five times more rule is figurative. If you take it at face value, it’s stupid and pointless. It’s just a guide to a different way of thinking.

When you estimate the cost of an IT solution, multiply it by five. What if you don’t have that amount? The same thing you will do if you need a 300k truck and can only spare 60k.

Yesterday I wrote that when you are about to automate your logistics business, you should be prepared to spend five times as much as you initially think. What if you don’t have that much?

When you are about to automate your logistics business, get into a mentality of “we are building it in order to throw it away”.

When you give an employee a device, you might need to give it bundled with a carrying case, a specialized charger, or a towel.

Celadon Trucking, one of the largest trucking companies, failed. This can happen to software companies, and the results can be worse.

When the Manchester ambulance dispatching service added decision support software, they had to change the way they were seated.

If you rush to adopt some automation without thinking about the repercussions first, you are headed towards a nasty disruption.

The story of Twitter illustrates how software can start OK and then fail big. Twitter was able to overcome the problems with a brave decision.