When things go wrong at work, the day can seem really long and hard to get through. However, the reasons behind why things are going south in a hurry might be beyond your control! You might be in the midst of an Engineering Law attack! Did you know that there are dozens of laws that can trip you up at almost every turn? In order to help you navigate this minefield of unintended consequences you first need to understand these laws and where they came from. Luckily, the internet is here to help! Below are a collection of the best of the best Engineering Laws that you can use to your advantage. Remember, forewarned is forearmed! Good luck!
Murphy’s Law
Anything that can go wrong will go wrong
Possibly the most well known of the Engineering Laws. This law, simply stated, declares that “Anything that can go wrong will go wrong.” We experience this law all of the time. When was the last time your favorite brand was the only one the company decided to stop making? Or the delivery you took the day off and waited for only to have it arrive when you stepped away for 5 minutes for a quick shower? How about the production release that managed to halfway post to the production server but that 1/2 that did post managed to overwrite the backups before failing so that the whole system was kaput?
Murphy is a good, general scapegoat for when things go bad. Don’t hesitate to blame him and his law early and often! However, keep an eye out for Murphy’s Law working against itself. That machine that you could not get to work no matter how hard you tried? Yeah – once your supervisor or the repair technician is standing in front of it it will undoubtedly work flawlessly. This law is not just mean, sometimes it can be disturbingly and, unfortunately, innocently evil.
Hofstadter’s Law
It always takes longer than you expect, even when you take into account Hofstadter's Law
Have you ever attempted project planning? Project overruns occur in terms of both cost and time. Take the Sydney Opera house for example. That amazing building was finished 10 years late. The cost? It was originally projected to be a cool $7 million but eventually wound up running a tab of over $102 million. What about the Eurofighter Typhoon military aircraft? If $95 million cost overruns don’t scare you, then how about the original targets for this fighter jet coming in at 7 years and £7 billion (currently about $9.3 billion USD). When it was all said and done the development window took more than 17 years and in 2011 one UK office estimated that total program costs would reach £37 billion (currently about $49 billion USD).
So you can see that even some of the smartest Engineering and military minds get project planning wrong! Don’t fret – this law has you covered. This law was coined by Douglas Hofstadter in a book written in 1979: ‘Gödel, Escher, Bach: An Eternal Golden Braid’ (Amazon referral link). In this work Hofstadter surmises that a person will always underestimate the time needed to complete a task, and furthermore, even with this knowledge and attempting to compensate for it, said person will still underestimate the actual time needed for completion. So sit back, relax, and chill out! You are in good company! If famous cognitive scientists can’t even get it right, how is one lowly Engineer supposed to hit the bullseye on project estimations? I suggest when asked to provide project estimates to roll a d20, slap that number in with an asterisk calling out Hofstadter’s Law and go on with your day!
Brooks’ Law
Adding manpower to a late software project makes it later
Oh yes. The perennial management solution to everything! Project running late? Add a few more people to it. It doesn’t matter if they know the product or project. Do they understand the technology in use? Don’t care! When project completion is relegated to a linear function that implies that all Engineer hours are equal and that as long as added Engineers are added to a project to soak up those extra hours it will result in faster delivery times there isn’t much that can be done to combat this methodology. In reality we know that any new person on a project requires ramp up time to get acclimated and start to be productive. Also as more people are added the overhead needed for efficient communication increases at an almost exponential rate. Finally, there are just some tasks that can’t be broken down and given to new people without them simply getting in the way and creating more havoc, chaos, and delays. Brooks’ himself states it best: “it takes one woman nine months to make one baby; nine women cannot make a baby in one month.”
This law is a godsend for anyone in this situation. Proclaim it loudly and proudly when your project gets late and keep chugging on. Hide behind this incontrovertible law and keep moving forward. Don’t worry that this law has many caveats – they won’t help you now. While adding people earlier in a project can mitigate many of these issues and ignoring the fact that highly skilled people need less ramp up time, your project is already late. Bow down to the law and just move on.
Linus’ Law
Given enough eyeballs, all bugs are shallow
Ever had that bug that is so maddeningly and frustratingly difficult that you felt that you would never find a solution? You weren’t following Linus’ Law! This law was formulated by Eric Raymond in his book The Cathedral & The Bazaar (Amazon referral link) and named in honor of Linus Torvalds. It basically states that with enough testers and developers on a project nearly every bug and issue with the project will not only be quickly identified, but the solution will be obvious and easy for someone.
Seriously, if you are still struggling with a bug then you simply do not have enough people looking at the bug and the solution – it will make sense to someone right? Following Linus’s Law, there is someone out there that will be able to fix this in a jiffy so it isn’t your fault that management has decided to put you in charge without any of these imaginary infinite testers and co-developers in place to help! Your lack of a solution here is totally not your fault – blame management and Linus’ Law and you are good to go!
Conway’s Law
Organizations which design systems are constrained to produce
designs which are copies of the communication structures of these organizations
A programmer named Melvin Conway came up with this law in the late 1960s. It infers that humans are unable to work together on one hulking code base and that individuals or groups will always introduce their own modules that are unique to the project. Therefore, the more people or groups on a project, the more unique code is introduced and the more complex the solution ends up being. And we already know that complexity cannot possibly be efficient, so the project might already be late!
Due to the fact that organizations tend to build solutions that reflect internal structure and methods, you are totally in the clear here. It can’t possibly be your fault that the other team decided to use tabs instead of spaces and your project is late because you had to refactor every sub-module to correct that glaring issue! If only they had let you do it all by yourself then the company wouldn’t be in this pickle! Sure, your estimations might have been off but the overall solution would definitely have worked right from the beginning no matter how long it took! Chalk another loss up to the Engineering Laws…
Wirth’s Law & Moore’s Law
Wirth's Law: Software is getting slower more rapidly than hardware is becoming faster
Moore's Law: The number of transistors in a dense integrated circuit doubles about every two years
Today is your lucky day! A double whammy of laws are totally wrecking havoc and causing your project delays. Don’t you know why even though your computer is getting faster and faster every year your code isn’t keeping up? Blame the laws! Moore’s Law is an amazingly consistent law that was first proposed by Gordon Moore in a paper in 1965 and still manages to be true today. While this exponential growth will hit a very physical limit at some point in the future, we are still living in a world bound by Moore’s Law.
Wait – there is a counter that gives you all the reason you need to explain your troubles. Niklaus Wirth first described his law in a 1995 article titled “A Plea for Lean Software“. He referenced Martin Reiser who wrote that “software manages to outgrow hardware in size and sluggishness“. Forward in time to none other than Bill Gates himself who postulated that: “The speed of software halves every 18 months” and there you have it. You are fighting a losing battle here! Every two years your computer will double in speed but your software will get 133% slower. Of course! This one definitely is out of your control and you just need to mention these laws to explain why you are slowing down year after year after year.
Parkinson’s Law
Work expands so as to fill the time available for its completion
The last, but certainly not least of our eponymous Engineering Laws. We have saved the best for last. The explanation for, and reason behind, bureaucratic overhead. That wonderful time suck that now requires three people to do the same amount of work previously handled by a single individual. A British Naval historian, Cyril Parkinson, first defined the law in a 1995 essay in The Economist. However, you don’t need to be British or in a navy to appreciate this law and its finer points.
Not only does this describe that wonderful excuse to fill up any extra time on a project with busywork, it also clearly elucidates the exact reasons why the application being developed grows to consume all available bandwidth, the database grows to fill all available storage, and the software uses all available memory. Not only that – but project feature creep will increase to utilize every person and resource and all available budget will be wholly consumed. Oh yeah – and your timesheet will also reflect that the same task that took 2 days last week is taking 4 days this week due to the fact that you don’t have any other pressing tasks after this one…
Congratulations! You have now graduated at the top of your class and fully have these amazing, wonderful, and supremely insightful Engineering Laws to use at your discretion! Use them wisely and liberally in your everyday interactions and they will serve you well now and for the next few days until management gets tired of your excuses and Murphy’s Law comes back to bite you and you are working on your resume instead of writing code! Thanks for reading!
Comments are closed, but trackbacks and pingbacks are open.