Hi. I'm jon.404, a Unix/Linux/Database/Openstack/Kubernetes Administrator, AWS/GCP/Azure Engineer, mathematics enthusiast, and amateur philosopher. This is where I rant about that which upsets me, laugh about that which amuses me, and jabber about that which holds my interest most: *nix.
Accidentally essential?
"Following Aristotle, I divide them into essence, the difficulties inherent in the nature of software, and accidents, those difficulties that today attend its production but are not inherent." -- Fred Brooks, "No Silver Bullet"
This is the second time I've referred to this particular paper on this blog. I've read it numerous times, and even though it was written in 1986, the facts set forth by Brooks still hold true today.
So there are two types of difficulties in any project: essential difficulties and accidental difficulties. Essential difficulties are the type of difficulty that are inherent to the project and are unavoidable. Accidental difficulties are the type of difficulty that are present but avoidable. For IT, essential difficulties would be scaling requirements, hardware failures, etc... the stuff that, regardless of how you approach the problem, will eventually occur. Accidental difficulties in IT are things like "PFY just accidentally removed the wrong drive in a degraded RAID 5", "The database was named 'demo', so I didn't bother backing it up and didn't realize it was the live site's db until after PFY removed the wrong drive", etc...
How nice would it be to completely eliminate "accidental" difficulties?
In the scenario given above (PFY removes wrong drive + bad naming scheme), it would be quite simple. First, don't let PFY handle mission-critical operations he/she is not qualified to handle. Second, standardize your naming schemes.
But are these really accidental difficulties? In any group of people whose size exceeds a certain threshold, you will find idiots. (The size limit depends on the larger group you select your individuals from...ideally, the group is of high enough caliber that you can select enough non-idiots to fill the positions you need). From an organizational perspective, you WILL eventually have to deal with employees who aren't "up to snuff"...especially in highly technical fields (There is more demand for highly technical jobs than the market really can support...good news for employees, but bad news for employers). Most organizations won't "sacrifice" a good technical employee to a management position...so it seems (too valuable to promote?). This accomplishes one thing: putting idiots in charge of competent employees. Does it need to happen this way?
To quote the "site reliability engineer-manager" who interviewed me for a job last summer, "We are a true meritocracy. The better you perform, the more you are promoted." Sounds nice, doesn't it? Imagine that...in exchange for your drive to learn and apply your knowledge on the job, you are rewarded with more responsibility and better pay. Sounds fair (and pretty obvious) to me.
Unfortunately, that's not how it typically goes. In my first IT job, I worked as a cable jockey/desktop installation guru. The company had hired me as a medical technician performing some basic medical tests, but after a year my request to move to IT was granted. I started at the very bottom, but I didn't complain. I performed my duties flawlessly and ensured that the mobile medical computers were 100% ready 100% of the time. After I'd been in IT long enough to establish myself as a competent IT technician, the IT team started investigating Linux as a replacement OS for their 100% Microsoft infrastructure. Lo and behold, they happened to have a Linux nerd on their team already...me!
Now, in a sane world, the duties would follow knowledge. In reality, however, the IT director (an MCSE who pushed his team members to pursue their own Microsoft certifications), took the responsibility of performing the assessment of Linux. I voiced concern to the IT director, and when that was rejected I utilized the company's open door policy to voice my concern to the company VP. I presented a logical argument in favor of at least allowing multiple assessments to be made to give a complete view of the potential (and I promised to perform my own assessment outside of company time, even!). The VP rejected my concern and allowed the IT director to steer the company away from an excellent opportunity.
Ok, so that's just one example. I'll give that. But it illustrates essential difficulties in technical fields: Business needs don't necessarily mesh with technical needs, and the ideal technical solution is rarely the ideal business solution. In a closed-source proprietary project, some suit is going to tell me how to write code...that'd be like me dictating fiscal policy to the VP's and CPA's. It's madness.
That's what I love about open source...it's a meritocracy. Granted, corporate influence is alive and well in open source (not so much with OpenBSD, but very much so with Linux), but that influence doesn't wholly dictate development. Projects are forked, alternates are born, and the community as a whole benefits from the detachment of business and technical.
Then again, open source depends on whatever hardware is available, and hardware is always very business-oriented. Perhaps it truly is an essential difficulty.
This is the second time I've referred to this particular paper on this blog. I've read it numerous times, and even though it was written in 1986, the facts set forth by Brooks still hold true today.
So there are two types of difficulties in any project: essential difficulties and accidental difficulties. Essential difficulties are the type of difficulty that are inherent to the project and are unavoidable. Accidental difficulties are the type of difficulty that are present but avoidable. For IT, essential difficulties would be scaling requirements, hardware failures, etc... the stuff that, regardless of how you approach the problem, will eventually occur. Accidental difficulties in IT are things like "PFY just accidentally removed the wrong drive in a degraded RAID 5", "The database was named 'demo', so I didn't bother backing it up and didn't realize it was the live site's db until after PFY removed the wrong drive", etc...
How nice would it be to completely eliminate "accidental" difficulties?
In the scenario given above (PFY removes wrong drive + bad naming scheme), it would be quite simple. First, don't let PFY handle mission-critical operations he/she is not qualified to handle. Second, standardize your naming schemes.
But are these really accidental difficulties? In any group of people whose size exceeds a certain threshold, you will find idiots. (The size limit depends on the larger group you select your individuals from...ideally, the group is of high enough caliber that you can select enough non-idiots to fill the positions you need). From an organizational perspective, you WILL eventually have to deal with employees who aren't "up to snuff"...especially in highly technical fields (There is more demand for highly technical jobs than the market really can support...good news for employees, but bad news for employers). Most organizations won't "sacrifice" a good technical employee to a management position...so it seems (too valuable to promote?). This accomplishes one thing: putting idiots in charge of competent employees. Does it need to happen this way?
To quote the "site reliability engineer-manager" who interviewed me for a job last summer, "We are a true meritocracy. The better you perform, the more you are promoted." Sounds nice, doesn't it? Imagine that...in exchange for your drive to learn and apply your knowledge on the job, you are rewarded with more responsibility and better pay. Sounds fair (and pretty obvious) to me.
Unfortunately, that's not how it typically goes. In my first IT job, I worked as a cable jockey/desktop installation guru. The company had hired me as a medical technician performing some basic medical tests, but after a year my request to move to IT was granted. I started at the very bottom, but I didn't complain. I performed my duties flawlessly and ensured that the mobile medical computers were 100% ready 100% of the time. After I'd been in IT long enough to establish myself as a competent IT technician, the IT team started investigating Linux as a replacement OS for their 100% Microsoft infrastructure. Lo and behold, they happened to have a Linux nerd on their team already...me!
Now, in a sane world, the duties would follow knowledge. In reality, however, the IT director (an MCSE who pushed his team members to pursue their own Microsoft certifications), took the responsibility of performing the assessment of Linux. I voiced concern to the IT director, and when that was rejected I utilized the company's open door policy to voice my concern to the company VP. I presented a logical argument in favor of at least allowing multiple assessments to be made to give a complete view of the potential (and I promised to perform my own assessment outside of company time, even!). The VP rejected my concern and allowed the IT director to steer the company away from an excellent opportunity.
Ok, so that's just one example. I'll give that. But it illustrates essential difficulties in technical fields: Business needs don't necessarily mesh with technical needs, and the ideal technical solution is rarely the ideal business solution. In a closed-source proprietary project, some suit is going to tell me how to write code...that'd be like me dictating fiscal policy to the VP's and CPA's. It's madness.
That's what I love about open source...it's a meritocracy. Granted, corporate influence is alive and well in open source (not so much with OpenBSD, but very much so with Linux), but that influence doesn't wholly dictate development. Projects are forked, alternates are born, and the community as a whole benefits from the detachment of business and technical.
Then again, open source depends on whatever hardware is available, and hardware is always very business-oriented. Perhaps it truly is an essential difficulty.
Total Comments 0
