Managing the unknown unknowns

Mitigating risk and optimization is critical in project management. It is necessary to have a plan to control the unknowns.

How do you control the unknowns? Yes, they are difficult the control in the beginning, but this process can be improved with time and data.

First of all, there are known unknowns and unknown unknowns. The known unknowns are issues that you know could cause issues. For example, if our systems are getting upgraded tomorrow, there may or may not be an issue leading to more downtime than expected. The unknown unknowns are issues that arise that you haven’t even thought of. For example, hardware failure on your development machine could be an unknown unknown.

Known unknowns are much better than unknown unknowns. Mitigated risks are much better than known unknowns. We need to account for as many [realistic] unknown unknowns as possible and mitigate any and all risks associated with them.

This is why planning is extremely important in Agile teams. Make sure you allocate time to keep track of the unplanned activities, unknown unknowns that occurred, and the level of impact of the known unknowns. As more data is collected, have them accessible for future use.

Padding time is a no-no, but if it might be ok when we start calculating the risks. I’m sure there’s some equation for risk mitigation that uses something like the expected value in statistics. I’ve worked for projects that used metrics of anywhere between 50%-75% utilization of actual available development time. This number shouldn’t be random, it should be carefully calculated and adjusted as the project progresses.

When the unknowns do occur, shelter as many people as possible from these risks, so the schedule is minimally impacted.

Be prepared for the opportunity

Networking is important. The world stressed this enough throughout my life. But is it really?

Networking is useless without a specialty. What will they remember you by? Why should they talk to you again? How can they help you when you offer no services?

You need a specialty. Something people can remember you by, something valuable you can offer that others can’t.

Then you need to broaden your scope. Something to differentiate you from the other specialists.

Because “luck is what happens when preparation meets opportunity,” and this is when networking is important.

Require JS Module Returns undefined

When a Require JS module returns a value but is returning undefined when injected, there may be errors without any errors shown in the console.

1. Check for circular dependencies

2. Check for dependencies that are missing from the undefined module

3. Check the shim to see if any AMD modules are included (they shouldn’t be in the shim).

Maximizing Efficiency and Work Output in Software Projects

In my mind, software development is very simple.

A developer is most efficient when they can work independently without requiring external input. For maximum work output, tasks should be separated and distributed to developers that match the skillset. Minimal communication is required, and the worker continuously adapts to become more efficient.

However, there are several issues with this approach.
1. Decreased job satisfaction.
No one wants to work on the similar tasks their entire career. The human mind likes to learn and be challenged.

2. Lower morale
Human interaction is lacking, and work, which consumes the majority of our day, will not be enjoyable.

3. Increased fatigue
I’ve read that we’re limited to an hour or two of continuous concentration. Attempting to maximize output will easily fatigue the mind resulting in burnout.

4. It encourages one-dimensional growth
There are benefits to specialization, but the world needs well-rounded citizens to make democracy work.

There are activities that may slow down work in the immediate run but will mitigate the above issues and/or potentially increase the rate of work output in the future.

1. Relevant job training
2. Pair programming
3. Mentoring/shadowing
4. Communication/dependency
5. Self-learning
6. Breaks

These activities are beneficial and necessary to mix-in with the daily grind, but they will not be as efficient as an independently working developer that has the right skill set.  Thus, in order to maximize output, these activities should not hold precedence over working independently unless the developer cannot work independently without guidance. If guidance is required consistently, tasking may need to be improved or the developer might not have the right skill set.

Most importantly, work output is useless if the project is headed in the wrong direction. It is absolutely critical the work is spent going towards the right direction, or the work will be unnecessary and negatively impact employee morale, etc.

When the direction is unknown, let the developers take a break while things are being figured out.

You Too May Be A Victim Of Developaralysis

David R. Lee:

The grass is always greener on the other side, but I believe it pays to know your options well.
After all, what good is a large toolbox when you only know how to use one tool?

Originally posted on TechCrunch:

Dear developers: Do you feel insecure because you’re only fluent in a mere eight programming languages used across three families of devices? Does exposure to yet another JavaScript framework make you shudder and wince? Have you postponed a pet project because you couldn’t figure out which cloud platform would be best for it?

You too may suffer from Developaralysis. Be afraid. There is no cure.

The panoply of options available to developers today is ridiculous. We’re choking on a cornucopia. Over the last few years I’ve been paid to write Java, Objective-C, C, C++, Python, Ruby, JavaScript, PHP (sorry) backed by various flavors of SQL/key-value/document datastores (MySQL, PostgreSQL, MongoDB, BigTable, Redis, Memcached, etc.) Do I feel good about this? Good God, no. Mostly I just feel guilty that I haven’t done anything with Erlang, Clojure, Rust, Go, C#, Scala, Haskell, Scheme, Swift, or OCaml.

I’m a victim of Developaralysis

View original 672 more words