Refactors and merging projects of Angular 4 into Angular 1.5

Last week I had to sit through a meeting where we were trying to figure out how to merge an Angular 4 app into an Angular 1.5 app.  First off, why?  The original intent was to merge the features of each project into one to create a new product.

Our defense was that we were using the latest, at the time, Angular library and that we had just finished a complete refactor and re-architecture of our entire project that took 2 months.  However, we lost the argument because the other project already had alpha/beta/production users.  What they had failed to do was a refactor, code review, or unit tests for the last year.  They have been working off of prototype code from the very beginning.

After the meeting I asked to have a static code analysis done of both code bases with HP Fortify and SonarQube.  The results were without question in our favor.  Both HP Fortify found 3 errors in our code which turned out to be false positives and SonarQube produced 0 issues, code smells, duplications, etc.  For the other project there were 130 issues with HP Fortify and 29 bugs, 3 vulnerabilities, 231 code smells, and 33% duplication with SonarQube.

Even after the static code analysis was done 4 developers took a look at the code base and it was even uglier than they thought.  Most of them saying they would be embarrassed to have the code base in their portfolio.  The code was hacky and only one developer was working on it for an entire year with no code reviews or merge requests.

Here is the rest of the story.  The project that came up with 0 errors was prototyped with minimal architecting effort, but got to a point after our MVP demo that it needed to be refactored in order to produce a sound and maintainable project.  What the static code analysis was not able to identify was the bad architecting that we originally did.  SonarQube found only 9 issues before our refactor.  I didn’t expect a static code analyzer to find out architecting mistakes, but the amount of difference between our code architecture before and after the refactor was massively different.  That is why we need some code reviews done to ensure that our findings for providing the accurate information to make a decision on our code base merge.

The obvious decision would be to merge our Angular 1.5 app into our Angular 4 app, but there is a business case that might not allow for that timeline, so we have prove our case that our technical solution is a better way forward for the business.

1/3, 2/3 Rule

BLUF: Give your team the time they deserve to accomplish their planning before execution.

During any operation in the military there is a rule of thumb that should be applied to any mission planning set.  The “1/3, 2/3 Rule”.  This rule states that you should only use 1/3 of the planning time for your planning and give 2/3 of the planning time to your subordinates.

For example, if you need to move a logistics package from Tampa, FL to Atlanta, GA and it needs to happen in 3 days,  then you should take 1 day (1/3) of the time to plan out the logistical movement at your level and then give your team 2 days (2/3) to plan out their part at their level.

If you think about this, then you are allowing the most planning time given to your teammates rather than being selfish and hoarding all of that time and everyone else’s time to create my plan and then throwing it at everyone else hours before the execution has to happen and expect a great execution to occur.  Also, if you wait until the end to give your teammates your plan, then your team is sitting around doing nothing and guessing about what actions they need to take to make this a successful execution.  They can only guess if you actually told them that something is coming down for them to get ready for.

This planning technique highlights a few leadership characteristics that I have discussed in previous posts.

  1. Don’t be selfish, be self servant.  Allow your team the most time to plan for mission execution.
  2. Provide a WARNO (Warning Order).  This will answer the 5 W’s for your team to prepare for without knowing the intricate details of the plan.
  3. OODA loop – Don’t let this 1/3, 2/3 Rule confuse to be a hard and fast rule about you do your 1/3 planning first and then they do their 2/3 planning.  This is still an iterative fashion that you should continue to feed information to your team as your receive it.

Contingency Planning

BLUF: There are times when you won’t have 100% of the answers to create a plan.  Creating a contingency plan is to account for the remaining percentage of the answers you couldn’t find.

Contingency plans are critical to any operations or projects.  It is the “if X, then Y“.  You have to be able to account for these possibilities.  Play devil’s advocate or punch holes in the plan.  In the military this is a common practice.  After we devise a plan a group will provide all of the counter plans that the enemy will execute.  This is all in the process of war-gaming.  In war-gaming you answer all of those IFTTT questions.

In software development you can also apply contingency planning.  Have you ever been creating an architecture design that requires other teams to provide services or architecture in order for your design to work?  I run in to it regularly.

  • What if we don’t have access to a SQL Server database?
  • Who controls federated logins?
  • When will customers transition?

What is your plan at certain decision points?  At some point you have to just build your solution knowing that you no longer have the ability to talk to a SQL Server instance and you have to use PostgreSQL.  You have to run with it.  Do you extend your deadline claiming you couldn’t get it done?

Always have a contingency plan for your project critical paths.  A contingency plan is not pivoting.  It is providing a solution to get over blockers or hurdles, and sometimes that solution is compromising with the product owner that there will be risks in the application if we cannot do things a planned way.  Eventually you need to accept the risks or mitigate some or all of them.  Only after that will you make the decision to not deliver on time because the risk is catastrophic to cause customer issues – exposing confidential data.

It doesn’t take long to run through some simple scenarios where you think something might go wrong.  Cover your bases in the situations that you don’t have accurate or unknown answers.  What database will you use if you don’t have access to a SQL Server instance at the current moment when you are designing and planning.

What do I work on?

BLUF: It’s not the worker bees job to prioritize everything, be creative and work on items that you think need to be fixed if no other tickets are available.

Last week I had a team member start a discussion revolving around how we don’t have a full list of tasks for a feature set that we are working on.  He also mentioned about how we should be more agile about our tickets.

We are working on a SaaS product that has arbitrary deadlines with feature sets that need to be deployed on these deadlines.  My position with agile development is that agile is built around this understanding that a stakeholder cannot put deadlines on the team for specific features.  However, what a stakeholder can do is say “Ship it!” at the end of any sprint and it “should” work, but it might not be feature complete.  So we lie in the purgatory category of getting all the features done by a certain date with no ability to defer.  In the last couple weeks we didn’t have a large backlog to go diving into to grab more features, so the team member started coming up with ideas that he wanted to fix.  Awesome!  I always want people to be proactive about what needs to be done.  Don’t waste the day away by waiting for me to tell you what to do.  I am not always going to be able to tell you the next step right when you need it.

However, what did happen is that the next day I retasked him to focus on a different feature to fix that I thought could get done before our deadline.  The task I wanted completed would have been a better bang for the buck feature to demo to the client even though it wasn’t a big deal to code.  He wanted to know if he wasted his time doing something else for the day prior.  Absolutely not!  Taking the proactive initiative to do something else with the project without me telling him was the best event that could have happen.  The average of 4 hours that you waste on a task that didn’t go forward is part of the agile process (IMHO – i’m no “certified” expert).

During this whole conversation I wanted to get my point across that I want my team to be able to operate independently of me and a backlog.  This instills confidence in one’s abilities, creativity in the project, and independence from micromanaging.

I concluded the discussion with letting the team know that I would let them know if I thought they were underperforming.  I do my best to be very transparent so that my team knows I am telling them the truth aways and I admit when I don’t have the right answer or I am humble to admit I don’t know how to code something.  Being able to talk to people candidly is my only policy.  If I can’t tell the truth, then I need to hang it up and find something else to do.  Take a look at Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity.

Making fast and informed decisions

BLUF: Observe, Orient, Decide, Act (OODA)

As an aviator in the military there is a need to constantly scan your flight instruments and make quick corrections to maintain comfortable flight.  These constant corrections lead to a smooth and level flight.  Subconsciously you make decisions all the time, but the OODA loop is an explicit to make decisions quickly and always assess the next step to make another decision.  This is an everlasting cycle.


Every situation that you encounter where you need to make a decision requires you gather as much information as possible.  You will never be able to get 100% of the information you need to make the best decision, so you have to do your best to gain enough incite to make the best decision.


Now that you have a good source of information you need make a plan of action.  You must be willing to look at multiple courses of action that involve a IFTTT plan of attack.  In the military we look at two enemy courses of action (COA) at a minimum; most likely and most dangerous.  Your job, once you have gathered information to build opposing forces course of action, then you can create your own course of action.


Now you have to make a decision.  Choose which course of action best fits the situation.


This is self explanatory.  Don’t waste time with the first three steps if you can execute to effect change.

The beauty of this process is that you can apply it to small decisions or big decisions.  It allows you to quickly assess a situation, plan an action, decide on an action, and execute.  I have always heard that it is better to make an 80% decision quickly, then make a 100% decision late.  Don’t wait until it is too late to change the status quo.  When the status quo changes then you start the cycle again.

Balancing risk and information will lead making great decisions.  My senior pilot kept saying in certain situations – “This decision will either make you a hero or a zero.”  When you think about that with the balance of risk and information, then you are taking a big risk on just enough information for you to succeed, but the risk is so large that if you succeed, then people are amazed at your wizardry, but if you fail, then everyone will tell you how stupid that was.

Proactive Decisions

Last blog post I talked about the MDMP process in the military and how you can apply it to everyday problems.  I want to expand on this process just a bit and show you how to get your team involved in the process…

During MDMP there is a big chunk of the process that is completed without your input or decisions.  These are really mini decision points, but the big take away is that those decisions cannot be made without your guidance.  It all goes back to your mission statement and intent.  With these key pieces of information and confirmation that there is understanding and collaboration amongst the team, then you might as well micromanage the entire project and treat everyone like school kids.  Having someone lurking over your should every couple hours to make sure you are doing it their way is a sure fire way to make everyone on your team quit the project or even the company.  The best way to think about it is to become an enabler for your team and your teammates will hopefully reciprocate that love and enable you to accomplish your mission and goals.

There is a method to the madness of exposing your “vision” in a project.  When you let your teammates know what you see for the future of the project, then you empower them to help make decisions, add tasks, remove tasks from the board, and be creative!  What you really are looking for is for team members to step up and be proactive about what comes next in your project.  This enables you to worry about the nuances of being a manager: interviews, timesheets, and meetings (just to name a few). Yes, that’s the life of a manager role.  You have to keep the machine turning.

What does it mean to be proactive?  Well there is the definition, but my version is doing things that progress the betterment of the team.  This means to do the design up front, write the unit tests, and create some resemblance of common documentation.  I will admit, this is my order of priorities too.  I always leave documentation until last, but that also means that the team has to communicate in order to know what is going on in the architecture and system.  Therefore it really foster’s collaboration, right?  No, that is an excuse.  I hate writing documentation as much as the next person, but that is why they have a technical documentation profession separate from software engineers.  However fostering your team to be proactive when it comes to solving problems means that there is good communication and understanding amongst the group.  Your vision is being absorbed!

Now.  What is a proactive decision?  Simply put it is the pairing of someone being proactive that helps the team make decisions.  Trusting teammates to make decisions allows them to bring solutions to the table.  This eliminates you from the input to the solution.  All your job is to do is say execute what you have told me or tweak these things and then execute.  For example, recently I was having a conversation with a team member about how to execute and data reduction problem.  We had the option to write SQL to find the result set, or we filtered the problem through a structure procedure in a Storm pipeline.  After discussing both sides, ultimately the decision was to go either way.  “But that’s not a decision!”  Well, it is because I knew what the team member wanted to do, but I didn’t want to make that decision for him.  He just wanted my input.  I wanted to layout my concerns and priorities, and let him decide which way was better.  I give that mad props for coming to me with a solution already concocted and an explanation behind it.  Now I had to play devil’s advocate and find the shortfalls in the solution.  Eventually there is a pro and con to both solutions.  One of the solutions works really well now, but might not scale well in the future.  Do we really need to pre-optimize?  Never!

Foster your team to be proactive and create solutions.  Give them leeway to flourish  and don’t smother them by micromanaging their every process or decision.  Build a team that will be able to work without you.  If you aren’t needed anymore, then you’re doing the right thing.  It isn’t job security to keep so much on your plate that you fail at half of the tasks.

Decision Process

Having people make decisions to help you before you even ask them is the best situation to have as a leader.  It means they understand your vision and guidance without confusion or misunderstanding.  As part of the military there is a process known as the military decision making process (MDMP).  The goal of MDMP is to provide a process to find the best solution to a problem.  It is geared specifically to small or large scale military operations, but you can apply it to everyday tasks or problems.

MDMP Steps

  1. Receipt of Mission (What is the problem?)
  2. Mission Analysis (What needs to be done and what are factors that are effecting the solution?)
  3. Course of Action (COA) Development (What are the viable solutions to solve the problem?)
  4. COA Analysis (What is the result and overall effects of each COA?)
  5. COA Comparison (What are the compromises or pros and cons  to each COA?)
  6. COA Approval (Which COA is the final one to execute?)
    1. Orders Production (Who needs to know what to do during the execution of the solution?)mililea

These steps occur in order, but you might have used these similar tactics to solve a problem without a full 7 step procedure.  Apply this process to pouring a glass of milk when your current position is sitting on the couch.  It might seem dumb to ask yourself 7 questions to get this problem solved, but you do it without even realizing it because it is natural to you.  This vignette seems very watered down to the normal situations where you would apply the MDMP process.

If we dig into some of the sub parts of how a staff or team utilize this process we have to start with some common understanding.  Common understanding has to start with the leadership or commander.  An output from step 1 is the mission and the intent.  These two pieces of information drive the entire process to a successful end.  If a member of the team does not know what your goal/mission is, then how to expect them to do work that relates to the final product?  What about if they don’t understand your intent and they accomplish a product that solves the problem but they added or removed features from the final product that doesn’t meet your criteria?  How can you expect your team members to make decisions or take action in your absence without understanding these two key items?  You might think that they are not doing good work and therefore might lead you to micromanaging their every move when in reality you never gave them understanding or enough information for them to execute your plan.

In steps 2-5 team member(s) are left to come up with a plan of action to solve the problem.  During these steps the team will have questions that come to light.  Answers are provided by me or the team to keep everything rolling along.  In the end there will be one or multiple COAs.  This all leads up to step 6 where my team brings me all the solutions that they have come up with and we decide on a single solution.  Once the decision has been made for a solution, then it is time to execute which is step 7.  During this entire process the team has been collaborating and all should be close to or right on track with the plan of execution.  There is nothing to go back on once you hit step 7 unless you need to inform other parties that were not involved in the MDMP process.

One of my goals as a leader is to delegate tasks.  I can’t do everything and I have to trust my team to execute effectively.  In order to delegate to the other team members they have to know your expectations which would all be laid out in the mission and intent.  This all leads to effective teams that are proactive and productive.