There’s Stack overflows data from their annual survey. But a lot of people using Stack overflow can’t code. Just look at the questions. Many are complete beginners, many have not worked on a production project.

To further strengthen the aspirational nature of the responders, one can consider development tools vs platforms – most used microsoft platform products such as Visual Studio Code, Visual Studio and Notepad ++ ( 50.7%, 31.5%, 30.5%), yet listed Linux as favorite development platform. One could wonder how much Linux they use daily, whether in production, development or deployment. 

However, out of professionals surveyed, male developers were less interested in company culture than women. Both genders despised meetings. Compensation is important, but so is opportunity to grow, the software stack, and not pulling overtime.

And developers hate open space offices. Give your teams the opportunity to have a space of max 7 people and put in noise booths and meeting rooms, and see their productivity and happiness improve. No, do a test, really. We did. I do not accept shared open space for my teams.

Many of those items can be offered with no financial expenditure on the employers part. Several software development frameworks allow  eliminating deadlines, and if You can offer life-work balance, there are developers valuing that quite highly.

The cult of the 10x developer so prevalent in America does not seem to have the same cachet in Europe. Perhaps it is thus not surprising that Spain has more happy developers than the US. Is it the siesta?

When working as a project manager in tech, the developers one gets are a crucial part of the puzzle. I prefer to work closely with HR, ideally not letting them filter out the resumes.  I don’t care about EQ if the code is good enough. Then again, a self-assigned genius can produce unmaintainable code and take down the team with them. So the answer, as always, is “It depends”. No profound insight there.

But no, just because the demon of FAANG offers a salary Your company cannot compete with does not mean You cannot find good developers. How often does Your organization ask “What do developers want?”

As far as competent programmers go, it is,  and shall continue to be, their market.  What can You offer to them that others can’t?

We’re all gonna die. We’re all gonna die. Call it entropy. Call it the Pareto principle.  80 percent of everything is shit.

Projects are no different. The majority are not going to deliver any value. Never mind that they are going to go over budget and deadline while still not delivering said value.

Let’s get into defining value later. Because really, no one wants to touch that monster. Let’s start with the good old classics. PMI has a handy list of magic bullets  to take the pain away.

• Recruit and maintain adequate technical and non-technical resource skills
• Manage the allocation of scarce resources
• Define and collect operational metrics to support project and stakeholders decision making
• Promote efficient and effective communications
• Select and utilize technology related tools

In short terms, one can apply this methodology while singing “I want to ride my Waterfall, I want to ride my faaal!”. Because it sure appears to be good old classic waterfall model development.

We’re in IT. We cannot recruit “adequate technical skills”. It doesn’t work for google. The guy they paid hundreds of millions a couple of years back as benefits for exemplary service? They’re trying to send him to jail now. For trade secrets theft.

What makes us think we can do better?

With customer fit development ( agile and lots of other frameworks ) having a slightly more realistic approach, we are going to dive into the basic atoms that make up successful projects in future posts.

Catastrophes are often triggered by small project mistakes. Usually, there are several insignificant causes, combining for a large effect. Horror stories from different industries allow keeping a fresh perspective on the may blind spots and biases we all harbor.

One of my favorites, Fission Stories by Dave Lochbaum  is a column featuring (sometimes hilarious) mistakes in the nuclear industry.

Wrench in the machine

Some lessons are obvious and well known: when designing for safety, treat the end users as, if not outright malicious, then very dumb: If not actively circumventing safety, as above, jamming critical safety valves to “make the job easier”,  they can at the very least make the worst possible choice due to lack of training or training.

This, however, is only half of the equation. The ultimate responsibility lies with the designer, as workers exposed to routine workarounds due to inefficiency of the original blueprint stop respecting the grand scheme of things altogether. In the example above, there were flow blockages in the system.

As outlined in the column, “The practice of forcing operators to cope with equipment not performing per design is called an “operator workaround” in the nuclear industry. ” The company did not want to treat the first signal of failure out of spec as a cause for concern, requiring repair or replacement on first occurrence.

The employee on the ground took it as a signal to disregard stringent safety and devise safety shortcuts.

Big buckets of critical mass

The Tokaimura plant uses highly enriched uranium that requires stringent security precautions when preparing the fuel to avoid critical mass ( i.e. boom).

The Accident caused 2 deaths due to worker irradiation on site and payment of $121 million in compensation to settle 6,875 claims from people exposed to radiation and affected agricultural and service businesses. It occurred when employees mixed entirely too much uranium fuel in a wide tank as opposed to the correct tall one, “geometrically designed to avoid criticality” ( see illustrative video below )

To they layperson, this is a bigger plunder than putting diesel in your petrol car, even though fuel tank and fuel cap has markings identifying the correct fuel. No, this is adding a burning match to said fuel tank.

The nuclear refueling procedure had a state license, outlining correct operation. We presume the workers should have known that said correct procedure is the only way to avoid operator death. Max amount of enriched fuel allowed in the mixing tank  at any one time was 2.4 kg. They added 16 kilograms, 6,6 times over the safety limit.

Were they overworked and simply too tired?  Did they become complacent and cavalier?Did they have checklists? Did they check off each step before continuing? Did the fuel mixing procedure involve component delivery that physically limited the amounts added so as to avoid mistakes?

No surprises to the cause, unfortunately: “The crew assigned to process the Joyo fuel that day was under time pressure: The crew chief was anxious to complete the current batch before a new team of workers arrived. Furthermore, […]the workers were apparently not aware of the mass limitations on the uranium to be added to the precipitation tank ” [source].

Further,  “a widely distributed but unauthorized manual permitted the use of buckets as a shortcut in the process”[souce].  And how about  “A manager at the facility who was exposed to radiation at the scene reportedly told the police he “forgot” about the dangers posed by a self-sustaining nuclear chain reaction”.

But wait, for the final blow: “According to prosecutors, JCO also developed plans to hide illegal equipment and production methods from inspections”.

by Blake Burkhart

Certainly many a  project manager can agree that the causes are universal:

• Unauthorized process shortcuts.
• Poor process design, no built-in safety.
• Time stress, unrealistic deadlines.
• Lack of investment in safety culture. ( Continual improvement, PMI )
• Refusing to lead by example, insuring leadership sticks to safety standards and rewards safety thinking. ( Management responsibility, in PMI parlance )
• Lack of realistic training, including complete recreation of procedures in war-gaming scenarios on site.

Talking about nuclear, we of course have to touch on the worst catastrophes – Chernobyl and Fukushima.  I started with the smaller incidents as there the cause and effect are easier to identify. Yet the pattern remains familiar.

Chernobyl – poor reactor design, lack of safety culture, hidden design flaws known but masked but the manufacturer,  violation of safety guidelines, human factor. [source]

Fukushima, as outlined by Synolakis and Kânoğlu: “There were design problems that led to the disaster that should have been dealt with long before the earthquake hit.”  The  cause was a “cascade of industrial, regulatory and engineering failures.”  [source]

Now let us not forget the elephant in the room that the nuclear industry does not want to address: multiple nuclear reactors are designed the way they are since they are direct descendants of  military reactors ( see Soviet RBMK )  or part of the infrastructure subsidizing military nuclear industry ( see Hinkley Point C in the UK [1] ).

This will be addressed in a later post, suffice to say for now that nuclear energy is a vital solution to energy requirements, and it deserves an improved   philosophical approach to design and implementation. Case in point, molten salt reactors.

1. source: [https://www.nytimes.com/2016/10/11/opinion/britains-nuclear-cover-up.html?smid=tw-share&_r=1]

A collection of useful project management videos available online, not limited to PMI

Continue reading →