Radha Mukkai's Blog

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: All Problems are People Problems

One of the key insights I have learned from Jerry Weinberg’s book The Secrets of Consulting was that “all problems are essentially people problems”. In the world of software projects and technology, this may seem ironical. I have lived and observed the truth behind this insight on several software projects and it is useful to always keep this insight at the back of our minds.

As we try to create more complex products and work on complex projects, it is easy to believe that our problems and challenges stem from technology. As Virginia Satir correctly noted – Problems are not the problem; coping is the problem!

What matters is how we respond and combat this complexity. We always have more choices than we think we do. This also means that we have to take responsibility for our actions and failures (and the pressure is so much more!).

I have noticed that in situations where something goes wrong on a project, my initial knee-jerk reaction is usually to blame the circumstances and the environment. However, I have found it to be extremely effective and beneficial to stand back and ask myself the question – How did I contribute to this situation?

I always find that there is something I did or did not do that led to this situation. Once I stop blaming and get back to my power zone of determining what needs to happen, what actions I can take to facilitate a solution, and who I can approach to help me with the problem, the problem is almost always effectively resolved.

As Professionals, we must learn to cherish the fact that the buck actually stops with us!

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: Leadership and Process as our answers to overcoming the Sisyphean challenge

I believe the following ingredients helps us overcome the challenges with software projects:

1. Leadership
2. Process that incorporates early and rapid feedback

Leadership is an important ingredient for successfully overcoming the challenges posed by Software Projects. I have borrowed Jerry Weinberg’s’ definition of Technical Leadership. Leadership is about creating an environment that empowers people to solve problems. Software Projects requires diverse skills to succeed – Creativity, Curiosity, Discipline, Organization, Ideas, and Problem Solving. Leaders set the stage by promoting an environment where it is acceptable to fail or look bad and problems can be discussed openly without fear.

Process is very crucial to successful project delivery. More than the process itself, I believe what really adds value is if the process allows you to gain valuable insights that help you steer the “project” towards success. Process must incorporate early and rapid feedback (peer reviews, code reviews, demos, stand up meetings, status meetings). The important takeaway about feedback is that you need to make course corrections based on what you hear, see, and/or observe (using good judgment)!

An interesting insight from the Software Engineering Institute (SEI) was that effective management/leadership had to be in place before you try to incorporate new and better processes and development practices.  Process changes that come before establishing leadership have a high probability of failure.

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: The primary sources of imprecision are Communication, Thinking, and Execution

I believe there are three primary areas in which we can find imprecision in software projects:

1. Communication
2. Thinking
3. Execution

Communication

I have observed that common software engineering terms used on projects such as Requirements, Engineering, Quality, Design, Architecture, Testing, Schedule, Plan, Risk can be misunderstood or misused by various stakeholders. Imprecision and sloppiness in our language contributes to faulty actions and poor outcomes. I have observed several instances when I have confused Quality Assurance with Testing, Risk with Issues, and Plan with Schedule.

We cannot deliver Quality products on the foundation of weak communication. Our language must represent the preciseness that software demands from the teams. During my exploration to understand the word requirement, I found that there are several competing definitions and each one of the definitions highlights a particular aspect of the term. There is a lot of nuance and significance surrounding this deceptively simple term. This holds true for the other terms I listed out as well.

Let us say we do a quick survey of the project team and ask them to define the word requirement. Are we confident that all of them would provide an answer that is in the same ballpark? What are the effects on the project if various stakeholders and team members hold divergent opinions on what constitutes a requirement? It is important to be aware of such divergent viewpoints and determine ways in which we can precisely communicate our thoughts and ideas.

Thinking

A lesson I have learned from Jerry Weinberg is that our mental models shape our actions and communication. Let us think about the word defect. What does it mean? We can think about defect as any deviation from the requirements document. We can also think about defect as a deviation from stakeholder expectations. I believe we can observe demonstrable differences between testers who hold these different beliefs. Each one will approach their work and craft differently based on these beliefs. Their actions and communication will reflect their different mental models.

The same applies to other aspects of Software Projects. What are our mental models around Leadership, Project Management, Design, and Architecture?

Execution

I have observed that it is easy to fall in love with technology and forget the end goal of a project. The goal for projects is to deliver a product that stakeholders find valuable. Once we lose sight of the goal, it is easy to fall into certain traps – We may start equating “code complete” to “complete”. Once we fall into such a trap, our plans and communication of status will not be credible. “Code complete” by itself does not add any value. The value is in delivering the product!

We need to estimate, plan and prepare schedules keeping the end goal in mind. We need to keep asking ourselves, what does done truly mean for this particular project? Is it done after we complete writing the code? Is it done after we run our automated suite of unit tests? Is it done after testers have evaluated the product? These questions help us evaluate and understand if we are closer to achieving our goals or farther away.

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: Software can only be as good as the teams who build it

I found a sign near a developer’s cube that said, “Around here we do precision guesswork”. I loved this sign as it touches on a very crucial aspect of what makes software projects tough and so much fun! As developers and engineers, we have to navigate uncertain environments and deliver value to Clients and users. This requires a lot of precision guesswork! ;->

Software programming and managing projects is a highly cognitive and mental endeavor that requires the ability to think big picture and be detail oriented. This is a tough juggling act and people can make the problem harder (or easier)!

Software Projects are ultimately a people business. At the end of the day, we are emotional beings and mask ourselves in the dress of rationality. We tend to use labels, generalize and can be vague about what we want.  People can cope well with ambiguity and uncertainty (and some do not!). Software cannot cope with ambiguity or uncertainty. Sometimes we fail to cope with these facts! ;->

Computers cannot think. Computers are not intelligent. Computers cannot reason. Computers cannot make value judgments. However, computers can be programmed to respond in a fashion that seems to demonstrate good judgment, and intelligence.

Software can only be as good as the teams involved in building it. The quality of our teams determine the quality of our products. Our teams are our strengths as well as our weakness. Talk about a paradox! ;->

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: Software is a precision business

When you have developed software for some time, some things become very clear. Software will do exactly what you want it to do.

When we think deeply about software, we need to realize that it is all about 0s and 1s. We manipulate 0s and 1s (and occasionally NULLs!) and we transport 0s and 1s over the wire. It is easy to lose track of this fact as we have built enough high-level programming languages, libraries, APIs, technologies, and tools that we never have to deal with 0s and 1s directly. Just like reality, the Os and 1s are always lurking in the shadows and never go away (even if we try hard to wish them away)! This is the gravity for software projects. You have to contend with this no matter what.

What does all of this signify? Programmings forces us to be extremely precise in stating what we want to accomplish.

Let us take a regular use-case. Consider an online banking login page that asks users for their username and password and allows them to access their account information.

Here are the various decisions that a software team needs to make.

1. What constitutes a valid username? Can it be 50, 100, or 250 characters long? Can it include numbers, spaces, or special characters? What special characters can be allowed? Are there other restrictions?
2. What constitutes a valid password? Should users be forced to change their passwords every 3/6/12 months? How many attempts should the system allow before we lock the users’ account? What happens after the user account is locked?
3. What is the exact error message we need to display to the user if a problem occurs? What will be the font size and position of this message? Should we even display an error message? When should we hide the message?
4. What is the font size for the username/password label? What should we call these fields? Are we referring to these fields consistently throughout the application?
5. Should the application support multiple browsers? If so, what browsers and what exact versions should we support?

The login page may seem to be a “simple” page on the surface. However, we soon realize that there are tons of decisions that have to be made. Each decision affects the size, scope, cost, and effort involved in completing the project. To make matters interesting, we have only scratched the surface! We have not discussed Security, Performance or Usability aspects for the page.

We need to make these decisions “consciously” as this will lead to a product that can delight our Customers/Clients. Can we ignore such decisions? Nope! One of the biggest challenges with software is somebody “eventually” makes these decisions! ;->

Let us take username. Let us say we decide not to establish the field length for username. At the time when the database modeler/programmer defines the field, she/he will set the field length! A decision is made for the product regardless of whether you agree with it or not! That is one of the reasons we need to be aware of what we are doing!

This brings up three important questions:

1. Is the right person making the decisions that help us be successful – Creating a product that delights our stakeholders or at least meets their expectations?
2. Are we making decisions consciously?
3. Do we understand the impacts of our decision?

In a field that demands precision, our decision making better be very good!