Recent Posts (page 11 / 70)

All Models Are Wrong, But Some Are Useful

As I’ve mentioned before, I’m a mechanical/aerospace engineer by training. My first job out of school was doing simulations to do trade off analysis on different aircraft configurations. Some were studies around mission effectiveness in different combat environments, and others were aerodynamic simulations to see what effect changing flight control software would have. In all of those cases we were using code to represent the various real-world systems and their interactions to predict what the results would be in the field. And we needed to do lots of trials.

This was 30 years ago, and the computers were slower, so we made lots of simplifying assumptions so we could get our results faster. First, computers are discrete, and the real world is generally, analog. We made time slices small and used all sorts of integration methods and feedback loops to make it seem like things were analog. Second, all that code was an approximation of reality. For the aerodynamics we took 3 and 4 dimensional tables (angle of attack, speed, altitude, and control surface positions) of flight data and interpolated between the data points. Which meant we left out a lot of things, like how all of those things (and others) were changing. For avionics and other systems, we used statistical data. How far away radar could detect objects of a given size. How effective missiles and countermeasures were. Again all defined in nice, neat, discrete tables.

In other words, a model of the systems. We knew they weren’t exactly correct, but we felt they were correct enough draw conclusions from the results. Which leads us right to

All models are wrong, but some are useful

        – George Box

Box was correct when he hinted at it in 1976, and made that exact statement in 1978. The models are wrong, but they’re useful in getting results faster, cheaper, and safer than you could by running those 1000’s of trials.

Box wasn’t the first one to talk about it though. Going back to the 1930’s, Alfred Korzybski talked about how maps represented something, and could be very useful, but they’re not the same thing.

A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.

        – Alfred Korzybski

Besides being a representation of a single point in time, in the past, maps don’t have all the details. Depending on how closely the intended use of a map is with how you’re using it those details could be crucial. If you’re out hiking in the bush, even the most detailed road map won’t help you know elevation. Conversely, a topographic map is great for hiking in the mountains, but not very good if you need to know which freeway to take between two cities. And that doesn’t even consider that the map might just be wrong.

A lot of software development is based on models and mental maps of the various domains. From Machine Learned models (Uber’s ETA or pricing models, ChatGPT and the various LLMs, etc) to expert based heuristics (financial fraud detection algorithms, alerting on operational metrics, etc), to something as seemingly simple as the state machine for bug tracking, we use maps and models to help us understand the dependencies and interactions between systems. The better the model (dependencies), the more accurate the predicted results (interactions), and the better we can use them to drive system behavior in the direction we want. Get it wrong and we end up with the cobra effect and things get worse.

Another way we use maps is data schemas. Schemas are maps of the structure of how the data is expected to fit together. We use the schema to store the data. We use the schema to drive how we process the data. We use the schema to define how we accept input and provide output. The closer the map (schema) is to the territory (the actual data and its structure) the more useful the map is. If the schema doesn’t match the structure, then you find people working around the system instead of with the system. Using and changing things becomes even harder than it would have been.

With all of that said, maps and models are useful and important. They reduce cognitive load. They easy communication. They let us get results without having to simulation every air molecule flowing over a wing in a continuous stream. You just need to remember that the model might be useful, but it’s wrong in one or more ways, and that the structure of the map is helpful, but you can’t really travel by map.

Mea Culpa, Mea Maxima Culpa

I goofed. One of the first things to do when you make a mistake is to acknowledge you were wrong. Back in September of 2021 I wrote a piece called Measurement where I listed a bunch of management quotes and said that it’s important to use the whole quote, not take part of the quote out of context. I believed that when I said it then, and I still feel that way now. However, I’ve recently been made aware that many of the quotes I’ve attributed to Peter Drucker weren’t actually said by him. I did a little digging, and if you can’t believe the Drucker Institute on what he didn’t say, who can you believe?

In this case, the quote was

What gets measured gets managed - even when it’s pointless to measure and manage it, and even if it harms the purpose of the organization to do so.

That was actually said by a someone commenting on a 1956 paper that criticized the first part of the statement. Which was the point of my post back in 2021, so I can feel good that I got that part right at least.

It turns out that what Drucker actually said was

Unless we determine what shall be measured and what the yardstick of measurement in an area will be, the area itself will not be seen.

That’s something different. Yes, it’s related to measurement, but has nothing to do with how people will respond to knowing that something is being measured. It has nothing to do with whether or not it’s something you should be measuring. What it’s saying is that you need to pick not only what you’re going to measure, but how you’re going to measure it. If you get either one of those wrong, you’re not going to see the reality of the situation you’re looking at.

If you’re not measuring what you think you’re measuring, what are you measuring? How are those measurements going to influence what people do? People work to control what is being measured. That’s a very common thing for people to do. However, if you’re measuring the wrong thing, you’re very likely to get a result that doesn’t move you towards the goal you said you were trying to achieve.

Consider measuring productivity. What does productivity mean? Sure, you could measure lines of code written, but that’s activity, not productivity. Measure lines written and you’ll get more lines written. Not necessarily good lines. Not efficient lines either. And there’s very little incentive to remove things that are bad. Probably not the result you want to achieve. You could measure tasks done, but that leads to lots of little tasks. Now taking many more smaller steps, and re-evaluating along the way, is a good thing, artificially dividing things up into tiny tasks and then just blindly doing them doesn’t get you a better result. Just because a task is done, was any value created or shared? And what does done mean anyway? A better way to measure productivity would be to somehow compare value delivered to users in a given time period. Of course, that’s easy to for me to say, but hard for you to determine. It’s hard because it depends on the context that you and your users are operating in. Get it wrong and you don’t get any visibility into the area you’re trying to measure.

Which is what Peter Drucker did say.

Permission, Approval, and Feedback

There are endless debates online about the relative merits of code reviews/pull requests vs Ensemble/Mob/Pair programming. I’m not going to talk about any of that. You can read about it at one of more of those links.

I’m going to talk about the world that many (most?) developers live in. Requirements are identified. Designs are done. Work is discovered. The work is turned into tasks. Tasks are prioritized. Tasks are selected by / assigned to an individual. The individual does the work in semi-isolation. There is a code review/pull request process to follow before the code is merged into the main branch and then deployed. There are lots of variants on that, such as requiring design docs, automated tests, code coverage checks, required reviewers, sprint planning, time boxing, and such, but that’s the basic flow.

At each of those stages, there is some kind of gate to get out of the current state and into the next one. That’s where the differences between permission, approval, and feedback become very important. At many places you are required to have someone sign off on the work done. There are tools and processes in place that ensure you meet the requirement. That’s permission. To follow the official process, you need someone else to put a stamp on your work and say it’s OK. Sometimes there is even a defined person or set of people who are allowed to say it’s ok. They also have the power to say no and then you can’t move forward.

The next level is approval. Approval is someone saying, “I can’t really stop you, but I think that’s OK.” Approval is nice, but it’s not required, and it doesn’t really mean anything.

Then there’s feedback. Feedback is really interesting. It can range from silence to “LGTM” (Looks good to me), to “This is a great approach and simplifies a complicated problem.”, to “This is the exact wrong approach, and will make things harder in the future.”, to a more generic “Here’s another approach that might make things easier.”, or “Have you thought about how this change will impact X? I think there’s some interaction there.” The thing about feedback is that while it’s a gift, you don’t have to take it. If you’ve got the required permission, then you can ignore the feedback and move on.

That’s the rub. The most useful information is often in the feedback. The part you’re most likely to ignore. Especially when the feedback comes from an unexpected place. If someone you didn’t expect to care, like a customer, user, or some team that thinks about non-functional requirements (like security, UX, QA, PM, Finance, etc.) takes the time to give you feedback, that’s probably the most useful information you’re going to get.

Those apparently unrelated folks have a very different viewpoint than you do. They approach the problem from a different place and are focused on their area. If someone from Finance says that they’re concerned about how this change is going to impact the bottom line, or the security team is concerned that there’s an uncovered vulnerability in the design, then there’s a problem. There’s at least a problem with the work you’ve done in that it doesn’t explicitly state that you’ve thought that issue through and have a plan/mitigation in place. More likely, they’re pointing out a blind spot in your thinking and it’s something you need to go think through and make sure it’s addressed.

In a perfect world, the folks that are giving you permission are paying attention to the feedback, and it’s good to have another set of eyes to make sure the feedback is addressed, but it’s not their job. It’s your job, as the person doing the work, to take the feedback, internalize it, and respond to it.

Any fool can write code the computer understands.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

    – Martin Fowler

I’ve talked about that quote, and coding for the maintainer before. I’ve mentioned Martin Fowler even more often. However, almost all of those have been more than a year ago, and it’s an evergreen topic.

Over the last 40+ years I’ve written code in lots of languages. Various flavors of Ada, assembly, Bash, Basic, C/C++, Cobol, C#, Forth, Fortran, Java, JavaScript, F#, Pascal, Perl, PHP, PL/1, and Python, to name a few. In all of those languages you can write code that, if you don’t touch it for a few months, you look at it and wonder what idiot wrote it.

With most of them though, if you take your time, think things through, and decompose things, its relatively easy to write code that at least the author can come back to later and understand what’s going on.

The one language that gave me the most grief though, was VBA in Excel. And the place that it gave me the most grief was in the Master Block Tracking (MBT) spreadsheet, back on the Global Ortho project. Imagine a spreadsheet with ~30 tables, the largest of which was about ~1500 rows and 75 columns. All to produce a single table that showed what work was in progress, what work was blocked, and what work had been recently finished. It worked, but it was a nightmare.

The reason it was a nightmare was not because it grew organically. It wasn’t because the requirements were unreasonable, or unclear. It wasn’t because the language didn’t support what I was trying to do. The reason it was a nightmare was because of the sunk cost fallacy and code that humans couldn’t read.

First, and most importantly, we used the wrong tool. We should have dropped Excel and moved to a website. That would have the problems of tiering, access control, change management, and making sure everyone had the latest version of things. But we didn’t re-evaluate the goals and work backwards. We just adapted the current system to work.

Second, the original, manually updated MBT had a set of auxiliary tables that the production team would update with the current state of the various processing pipelines. Then the MBT would do all the calculations in a combination Visual Basic for Applications (VBA) and calculated cells. And we didn’t change that. Instead of stepping back and redesigning things into a properly tiered architecture with a data layer, a business logic layer, and a display layer, everything other than data storage got mashed into spreadsheet.

Even if we wanted to use Excel as the display engine so that there could be offline analysis, we should have changed the design. We had calculated cells that lookups on top of lookups and then tried to calculate state. Instead of building intermediate tables based on the business logic and loading them into the spreadsheet, every cell did the logic needed and calculated the intermediate values locally. When there are 15 (yes, 15) closing parentheses at the end of the equation for a calculated cell, your code is essentially unreadable. And we had lots of different cells that had equations like that.

Every time we added a state, or changed the definition of a state, or had to handle a new edge case as we re-processed data, I would spend hours reacquainting myself with what I had done and understanding how things worked before I could start making the changes needed. For the last 9 months, I was the only one who could figure out what was going on and how to change things. Let me tell you, being indispensable is NOT a place you want to be. You might be needed for that thing, but you never get to do anything else.

Providing a way for our stakeholders to understand, at a glance, how things were progressing in the project, what they could expect to see released soon, and where the bottlenecks were is something that was essential to finishing the project and I’m still very proud of. The code behind that tool, on the other hand, is something I’m not very proud of. Because while the computer could understand what I had written, no one else, even me, could. That’s never a good situation to be in. I spent too many hours maintaining the system. Hours that should have been spent making things better instead of maintaining the status quo.

Now, when I run into a situation like that, I take the time to make things better. To make sure I’m using the right tool for the job. To make things more readable. To make updates easier. So that when I have to go back into something I don’t end up wasting a lot of time figuring out how and why I did something. Smaller functions. Stored intermediate values. Making the implicit explicit. So us poor humans can understand what’s going on.

Enter The Conversation

“Always enter the conversation already taking place in the customer’s mind.” ~Robert Collier

Interesting quote. It comes from the sales and marketing world. Basically, it says that your message will be heard better/clearer if what you’re saying fits into what your customer is already thinking than if it’s disconnected.

That makes sense. Sure, sometimes a cold call really does pique your interest and get you to follow up. The more common response to a cold call, however, is to just say “Thanks. I’ll think about it.”, then promptly forget about the entire encounter. Which, as a marketer, is the exact opposite of the desired response.

It’s a good point, and it explains why targeted marketing is a thing and why the online advertising market is so big. Advertising your sneakers to someone who appears to be looking for sneakers has a much higher likelihood of turning into a sale than advertising your sneakers to someone who’s sad and is looking for a funny cat video to cheer them up.

What has that got to do with software though? Of course, it applies to marketing software. But it applies to UI design. And documentation. And API design.

Why are people using your API? They’re (probably) not using your API because they like you and using it is fun. They’re using it to get a job done. That’s where they are.

That means that your API is a conversation with your customer and that the goal of the conversation is to get the job done. Your API should be written in a way that makes it easier to get the job done. It should be consistent. It should speak your customer’s language. It should hide complexity, not create it.

The key is having the conversation at the right level of abstraction. Let’s say you’re writing an API that a website can use to display and manage a user’s travel schedule. The API you build will be somewhere between a single function that lets the user make a single SQL call and a single function that returns the HTML to be rendered. You could do either one of those, but the former is really the API you’re going to call when you write a new API, and the latter is what the website is supposed to do.

Instead, think of it from the user’s point of view. What do they know, and what do they want to do? They know the end user they’re dealing with. They know if they want to display the existing trips, show the detail for a specific trip, add a trip, or possibly change a trip. That’s the information that tells you what your API should do. It also gives you good info into what you should call the functions, what the arguments are, and what the return values should be. That’s the conversation you’re having with your customer. In their terms, in their language.

Just don’t forget Hyrum’s Law 😄

Let Me Tell You What I Want

I’ve talked about user stories and ISBAT before. The idea that a user story should be focused on something the user wants to accomplish. The acceptance criteria (AC) should show how the result adds value to the user. While the AC’s are about the definition of done, they’re not about the steps along the way.

Very often however, user stories, especially on backlogs and on teams that work as groups of individuals, turn into tasks. One of the biggest reasons for that is that while ISBAT makes it clear what the end state is, it doesn’t really define the goal. Consider this user story.

As a customer, I should be able to check out.

The user is defined. The end state is defined. What more could you want in a user story? Consider this slightly extended user story.

As a customer, I should be able to check out, so that I get the product I picked.

The beginning of the story is exactly the same. The only change is adding the so that part at the end. It might not even change how you end up implementing the story. And if it doesn’t change anything, why write it down? It’s just syntactic noise with no added value.

However, there is added value. It’s slightly hidden, but there’s actually a lot of value there. The first version of the story is really just a task for the implementer. The second version is a task, with but with costs and benefits for the user stated. The benefit is that the user gets the product they picked. The cost is that they have to check out. When you recognize that you’ve but a cap on how much the “cost” to the customer can be. It has to be less than the value they receive. If the cost is less than the value, then you have a happy (and hopefully repeat) customer. If it’s higher you might have a one-time customer because of their sunk cost (they’ve already picked the product and done whatever else, so it’s worth it at that point), but you’re not going to have a repeat customer. From the customer’s standpoint there’s no value proposition.

Your goal, when coming up with user stories, is to ensure the story highlights the user’s value proposition, without constraining the folks doing the implementation. It lets the implementors working backwards from the user’s value proposition and maximize it.

If instead, you use this version of the user story,

As a customer, I should be able to get the product I picked.

you empower the folks implementing the solution to come up with a one-click solution. If you already know the user’s payment and shipping information you can have two buttons on the web page. One has the traditional checkout flow. Verify quantities, payment info, shipping info, and whatever else you need. And you can have a second one that says something like “Instant Purchase”, which takes those defaults, processes the order, and responds with a order ID and a tracking number.

That adds a lot of value to the user. It gives them the choice to pay the price in time and effort to go through the standard flow, or to save that time and effort. To have way to make the purchase with time and energy cost. It also gives the user more control over the process. Which adds more value.

Which is why you need to be care to not only make your user stories actually be user stories, not tasks, but also they need to be focused on adding value and improving the user’s cost/benefit ratio.

The Audience Is Listening

There are lots of ways to present information. When you’ve got some information you want to share it’s your responsibility share it well. There are lots of things to think about. Of course, you need to make sure the information you want to share is presented clearly, but that’s only the most basic, obvious, part.

Another thing to keep in mind is context. The context that you share with the people you’re talking to. Your audience. It’s your responsibility, as the person sharing the information, to ensure that you and your audience have a shared context. That the underlying foundation and framework that supports what you’re sharing is in fact also shared.

One of the big things in that kind of context is jargon. Oxford defines jargon as

special words or expressions that are used by a particular profession or group and are difficult for others to understand.

When you and your audience share those words and expressions you can take shortcuts. You can say one or two words and describe an entire situation. That kind of shorthand can be extremely useful to set the stage and make sure you and your audience are on the same page. As long as they understand the jargon.

On the other hand, if they don’t share the jargon, it makes things worse. Instead of inviting your audience in to join you, incomprehensible jargon pushes them away. It’s a barrier to entry. While the audience is trying to understand what you said, you’re finished the point and have moved on to something else. So not only did your audience not understand the jargon, they probably missed the next point as well.

Which gets us back to the title. They’re in the room. They’re probably paying attention. That, however, is not enough. You also need to be listening too. You need to know the audience before you start. If you expect the audience to have enough of the same context you can start with jargon and use it for clarity and brevity. On the other hand, if you think the audience doesn’t have the context, then you need to avoid jargon. At least at the start.

You also need to read the room, both while you’re speaking. Your initial understanding could easily be wrong. Is the audience leaning in and nodding? Are they looking confused? Are they asking questions to get you to define your terms, or are they responding with jargon and extrapolating from what you’ve said to what you’re getting ready to say? All of those things indicate that there’s a mismatch between you and the audience. And if there’s a mismatch between what you’re saying and what they’re hearing nothing is going to be shared.

It’s on you, as the person trying to share something, to be aware of the audience. To understand what they’re understanding and what they’re not. To adjust yourself to meet them where they are.

Because, of course, the audience is listening, so you should too.

Incident Response

As I’ve mentioned before, I’m a Mechanical/Aerospace Engineer by training, and plane geek. One thing I’ve noticed is that there’s a lot that software engineers can learn from aerospace engineers and aviation in general. One of those things is incident response.

A few days ago a couple of Alaska Airlines jets headed for Hawaii had tail strikes, within 6 minutes of each other.

Now tail strikes happen occasionally. There’s a procedure for it. The airplane returns to the departure point, gets checked out, and depending on the intensity of the strike, the passengers either continue on the same plane or a different plane is brought in and the passengers leave on that one.

Two in a row (6 minutes apart), at the same airport, from the same airport, with a similar destination, however, is not normal. There’s no defined procedure for it. Instead, Alaska’s director of operations looked at the situation and made a call. He declared an incident. All Alaska flights on the ground would stay on the ground until the issue was understood and mitigated if needed. It’s a safety of flight issue. When you don’t know what’s going on, stop and figure it out.

In this case, it turns out that a recent software update had some kind of issue. The flight planning software that was supposed to figure out weight and balance information and use it to set takeoff parameters had a concurrency/load issue. When operations got busy and built too many flight plans too quickly it got the weights wrong on heavy flights leading to incorrect power settings, which eventually lead to the tail strikes.

There are lots of lessons to be learned here. And that’s ignoring how the test plan for the software itself didn’t find the bug. First, the system has defense in depth against failures. The flight plan is designed to use less than full power to save fuel and wear and tear on the engines, but it doesn’t use the absolute minimum required. There’s a good sized safety margin built in. The pilots have a checklist involving the length of runway remaining, acceleration, speeds, and altitudes as the takeoff proceeds. If any of those checklist items hadn’t been met on takeoff the takeoff would have been aborted. Even with the margins and checklist, there were a couple of tail strikes, but there was no injury or loss of life, and minimal damage to the planes. One of the planes continued on its way about 4 hours later. The system itself is resilient.

Second, while there are no pre-defined triggers around number of tail strikes in a short period of time, the director of ops understands how the system works, recognized an anomalous situation. He was empowered to act. So he pulled the Andon Cord to stop things. There was a system in place to stop operations, so things quickly stopped.

The next step was information gathering. It quickly became apparent that the weight info was sometimes wrong. To resume operations the pilots, the line operators, who were most familiar with the weights and balances, were empowered to make a decision. They were told to check the weight, apply a TLAR (That Looks About Right) check, and if they felt there was a problem, to check with operations and get the right number.

22 minutes after operations stopped, they were restarted. Meanwhile work continued on a long-term solution to the problem. They handled things in the right manner. Stop the damage. Mitigate the problem and resume operations. Identify and implement the long-term fix. Figure out how the problem got into the system in the first place and make sure it doesn’t happen again.

That’s not just good incident response in a safety critical system. That’s how you should respond to every incident.

Done Done

One of the questions that gets asked a lot when you’re working on somethings is “When will it be done?” Lots of people want to know, for lots of good reasons. Leaving aside all of the questions around how to estimate (story points, blink estimation, bduf, etc), or if you should not even estimate at all, there’s still the question of what Done means.

This is where it gets interesting. According to Scrum, the definition of done is

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

– The 2020 Scrum Guide

which says approximately nothing. Just that you’re done when you’re done, with quality. So let’s break it down a little.

If you’re using User Stories you need to get them sized right. Even then, it’s pretty vague, since a user story is a placeholder for a conversation with the user. You’re not done until the user says you’re done. Then you’re done.

If you have a task list you might be in better shape. At least you likely have a list of acceptance criteria (AC). Your goal is then to meet the ACs with as little code as possible. Meet those criteria and you’re done.

Simple, right? Wrong. You still have lots of problems. In the user story case, you don’t know when you’re done until you get there. There is no definition of done, just a recognition of the fact that you haven’t gotten there until you arrive at done. On the plus side, when you’re done in that case you’ve added value for the user.

In the task list case, on the other hand, you know exactly when to stop. You’ve met the ACs. Unfortunately, just meeting the ACs doesn’t mean you’ve added any value. The task might is probably one small part of the work needed to do something. Updating a schema. Implementing an endpoint. Automating a manual step. None of those on their own add any value. The work you’ve done for the task probably needs to go through a set of deployment steps before it adds value. Those are probably tasks themselves and suffer similar problems. Doing a deployment without changing anything is good practice, but doesn’t add any value.

Which brings us to what I think done really means. You’re done with something when you’ve added value for someone. The definition of value, and figuring out who that someone is, are things worthy of their own posts in the future. For now though, a simple placeholder for value is “This work makes a user’s task easier.” Who that someone is can be anyone. It could be you, or your team, or a partner team, or even a customer. It really doesn’t matter.

That’s how you define done.

Engineering Project Risks

I’ve mentioned Gergely Orosz before. He currently writes the Pragmatic Engineer Newsletter and has worked at Uber, Skype, and other places before deciding to write his newsletter full time. He’s written about lots of interesting things, so check out his newsletter if you get a chance.

For those who haven’t subscribed to his newsletter, he also posts teasers and summaries on Twitter. One of them is about Engineering Project Risks. 7 types of risks and how to manage them.

1. Technology
2. Engineering Dependencies
3. Non-Engineering Dependencies
4. Missing Decisions/Context
5. Unrealistic Timelines
6. Not Enough People/Bandwidth
7. A “Surprise” Midway Through the Project

All very real and valid risks. And the mitigations are pretty good too. There’s another one though, a combination numbers 1, 2 and 4, that I wanted to bring up.

It’s the New Domain issue. Consider the case where you’re part of a new team being formed to address pain points in a domain no one on the team is familiar with? Someone with domain experience has identified a very real pain point. They’ve also identified a direction for a technical solution. The team now needs to figure out how to design and implement something that eliminates the pain point(s).

There are multiple things you’re dealing with at once, and all are important. I’d say they break down into 3 major areas:

Team Dynamics

It’s a new team, so all the issues a new team has are in play. The team will go through at least the first 3 stages of Tuckman’s model. Critical at the beginning is building trust. Trust that the idea makes sense. Trust that the team has the support it needs. And most important, trust within the team.

The best way to build that trust is Honesty and openness. Everyone saying what they know, and admitting when they don’t. With a foundation of trust the forming and storming is minimized and the team can do its norming.

Domain Context

Not only does the team not know each other, they don’t know the space they suddenly find themselves in. There are folks in the domain that are using existing technology. They’re using jargon and acronyms that the team doesn’t know. They have a set of shared beliefs about what they can’t touch and why.

Here, that lack of context is also one of the team’s greatest strengths. Asking questions to learn, and then sharing the new info across the team helps generate trust within the team and between the team and stakeholders/partners/customers (see above). The lack of context also lets the team look at things in new ways. After all, one of the 4 categories of information is the things we know that just ain’t so. As a new team without context you don’t know those things, so you ask the questions and approach things without those blinders on.

Dependencies

Sure, there’s lots of ambiguity, and there’s no existing code. You probably think you’re working on a greenfield project. But really, it’s a brownfield project. Unless you’re doing something entirely self-contained, you have dependencies. If nothing else, there’s the hardware and operating system you’re using. And way more likely, there’s a lot more you depend on. You’re using libraries and tools and systems that are developed and supported by other teams. Other teams with their own goals and priorities.

Here the lack of context and ambiguity is working against you. You don’t know what you don’t know, so you need to clear up the ambiguity. You need to figure out what you don’t know, then identify you’ll figure it out. You need to identify the dependencies and their limitations. How you’ll work with them. Again, openness and honesty are your superpowers here. The more open and honest you are, the better the answers you’ll get.

And of course, once you get through the special risks of a new team working on a new project in a new space, you still have to deal with the same set of risks as any other project. For that, I refer you back to [Gergely’s list (above).