Nine Women CAN Have a Baby in a Month

As technologists, we often contain a creative side within our DNA. In past articles, I have made mention of my early years being focused on playing the piano, which certainly favored my love of music. Working for a myriad of customers and corporations for nearly 30 years has made me realize that I am certainly not alone with having the ability to be creative.

This creative side can be an asset in my role — not only as a designer and developer of applications and functionality but in my thought process while I interact with my clientele, associates and personal relationships. By maintaining this trait, I believe that solutions for complex situations become slightly less complex with the ability to lean toward a creative mindset.

However, at the same time, the ability often leads to wanting to look at things from a different perspective.

Nine Women Cannot Have a Baby in a Month

The phrase "nine women cannot have a baby in a month" has been popular for quite some time now. It disbands the notion that if something takes a single person nine months to perform, that you can reach the same goal by utilizing nine total women for a single month. Of course, biologically speaking, this is currently not possible with the reproductive system.

In this article, I am going to talk about a case where that notion was falsified...but not without consequence.

The Need

My team was part of a large project that had a drop-dead target date that was driven by a factor that was out of the client's control.

While taking a step back, one might initially assume like this situation is rare. I certainly did, until I thought about just how many times I have been placed in this very situation. Aspects of each project have found a way to be in at least one article I have written about on DZone.com.

In this particular case, the leadership team at the client knew the following items:

• The end date of the project could not be changed
• The initial release feature set could not be compromised
• The pace of the existing resources was not fast enough to reach the goal

Our team was working hard, but there were extraneous factors that caused our pace to not stay on track to meet the goals of the initial release. Some examples:

• Depth of requirements did not reveal the true breadth of factors involved
• Delays in resolving blockers outside our team's control
• Lack of domain knowledge, especially related to interactions with other systems
• Changes in scope from leadership for items that were absent from the original plan

To most, these examples are certainly nothing new. The leadership team recognized the reality but still wanted to meet the deadline of the project.

The Decision

With what they felt like was their best option, the leadership team decided to increase the number of teams and staff on the project to a larger scale. In essence, this deadline (i.e. the baby) was going to be delivered in a fraction of time the current team's (baby's future mother) pace — by using other teams (other women) to help carry the load (develop the baby).

The decision was made to debunk the statement that "nine women cannot have a baby in a month".

Our team was certainly impacted by this decision (i.e. Brook's Law). Initially, to help communicate the details behind the remaining work, then to help determine the timing by which the features could be created and delivered. We also found ourselves spending time getting the initial team’s setup, troubleshooting challenges with their technology and configuration.

Once the teams were in place, our team was required to work through the pull requests (PRs) being submitted by the additional teams. This was due to a lack of bandwidth on the client-side and required a certain level of multitasking — which is typically something feature team members should avoid.

The Result

With the additional teams added to the project, the number of lines of program code written was far greater than the results by our original team. More tickets were getting worked on, tested and moved to a resolved state. Taking a step back and looking at things at a higher level, the decision to allow eight additional women to assist in a rapid gestation period looked to be a success.

However, what was missing was the impact on a lack of "domain knowledge" by those extra teams participating in the aggressive schedule.

The commodity of domain knowledge is very important for even a modestly sized application. Even with tickets that provide significant information, a lack of domain knowledge can cause the feature team to make design decisions that are not valid. While these tickets may have been marked as resolved, because the acceptance criteria were 100% met, the logic employed in the underlying program code failed in at least one of the following areas:

• Due to a lack of oversight, design decisions led to incorrect code — often reproducing bugs
• Introducing anti-patterns, which introduces supportability challenges
• Delivering a design which does not perform well — especially under a production load

Unfortunately, there is no fast-track to gaining domain knowledge and the results of this reality are inherent within the delivered code stream.

Conclusion

With the approach employed in the example above, an individual saying that "nine women cannot have a baby in a month" is incorrect. On more than one occasion I have witnessed this statement be debunked.

However, one has to be careful of what they wish for since the result of that desire just might not worth the effort endured. Sticking with my metaphor, science may reveal the ability to speed up the time required to prepare a child for birth. The consequences of taking this route likely far outweigh the benefit. At least that is my experience when taking such an approach with an aggressive deadline.

Have a great day!