6 Basic Laws an IT Professional needs to know

How to sound like you know what you’re talking about

Quite often when in IT Management meetings sage advice is offered.

You’ll hear these eponymous laws thrown around; they are mainly used to quickly demonstrate a point or the reason for unfavourable outcomes.

Knowing what these “Laws” are can keep you focused on the conversation without having to quickly do a Google search and then play mental catch-up as the conversation moves forward.

Moore’s Law

This is the easiest one and probably the one you already know. It says that that:

the number of transistors in a computer chip doubles every two years

Some people will say that the period is quicker — about 18 months. Others will liken transistor count directly to computing speed. i.e. every year and half everything doubles in speed.

There are many graphs online that show this to be true, starting from the early 70’s and going up to present day.

Forecasters state that the law will cease to be true come 2025, especially with regards to the number of transistors that can fit on a chip. However, the doubling of speed could still continue with the advent of future technologies such as quantum computing and Intel’s latest announcement.

Brooks’s Law

Humorously stated as:

Nine women can’t make a baby in one month

More often known as:

Adding manpower to a late software project makes it later

It’s a quick retort to the unseasoned IT Manager that believes that throwing more people (they would probably call them resources) at a problem will speed things up.

This law applies to knowledge workers, as the requirement for onboarding, increased communication channels and co-ordination takes its toll on an already stressed delivery.

Adding more people can have its benefits, but this practice is more applicable when building a bridge.

Parkinson’s Law

The date driven stakeholder will hold up Parkinson’s Law against the Kanban workflow.

Work expands so as to fill the time available for its completion

If you’re given 9 weeks to build a database, you’ll take 9 weeks. If you’re given 2 hours, then a database will still be built.

From a productivity standpoint there’s a lot of value in timeboxing your activities. Less procrastination and more output will occur if you’re working towards a deadline. Whether that be external or self-imposed.

What should you say to your date driven stakeholder? You talk daily, look at cycle time metrics and you’re also not completely oblivious to dates just because your entire workflow isn’t timeboxed.

There is an Asimov corollary to Parkinson’s law:

In ten hours a day you have time to fall twice as far behind your commitments as in five hours a day

Conway’s Law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Basically, how you structure your departments and teams will impact on how your day-to-day communication occurs.

Many organisations claim to be Agile, with Agile teams. But quite often they’re comprised of a Backend Team, Frontend Team and a Test Team. When work has finished on one team’s component, they’ll “throw it over the wall” to the next team with little care for the bigger picture or direct collaboration. Handoffs and communication channels are increased.

If you physically break down these silos at the organisational level, then these problems will ease away over time.

Wirth’s Law

This states that:

software is getting slower more rapidly than hardware is becoming faster

It comes under many other names, but Wirth was the first.

Variants of this law state that:

Software efficiency halves every 18 months, compensating Moore’s law

So why is software getting slower? Feature bloat, unkempt technical debt, greater commercialisation in IT and the general requirement that users need their software to do more.

It’s a complicated practice with little time taken on optimisation unless it really hampers user experience.

Theory of Constraints

This could have an entire article written about it alone. But in very simple terms:

you will come up against a bottleneck when developing and maintaining software.

You need to understand this bottleneck and what its impact will be on the delivery of the entire system. With echoes of Brook’s law: there’s no point in having two people working on a requirement instead of one if that requirement is itself blocked by a 3rd Party external dependency.

There’s no need to optimise components x and z of a system if component y still means that the end result is largely the same.

Systems have input and they have outputs, but the stuff going on in the middle needs to be known and understood if you are to properly optimise your delivery times, people and value that your system gives.

Bonus — Atwood’ Law

As I wrap this up this post like a present in time for Christmas, let me bestow on you one last gift :D

Any software that can be written in JavaScript will eventually be written in JavaScript.

Notable examples are:

• Doom, the 90s First Person Shooter

There were other examples, but Doom is the greatest.

Thank you for reading this article! Please leave a comment if you have any questions or feedback.

If you enjoyed this article then please consider buying me a coffee:

Chris Sheldon is a Project Manager for DataArt Ltd. DataArt are a global software engineering firm that takes a uniquely human approach to solving problems.

In his career Chris Sheldon has been a Software Developer, Scrum Master, Development Manager and more. He’s decided that people are harder than process, so this is where his attention is now targeted!

Chris graduated in the UK from Reading University with a degree in Electronic Engineering and Cybernetics.

A bit of a Agile enthusiast, productivity nerd and Wantrepreneur Chris really needs to decide what he wants to do in life and focus.

You can connect with him on LinkedIn, Twitter, Facebook, or by visiting his Medium