Wednesday, October 28, 2009

A General Learning of the whole Cat Team

This is a much simpler lesson than the hardest lesson of the cat team. Maybe you shall find it easier to grasp too.

Before the Cats got Lean and Mean
When the Cats were going through the last phases of kittenlife and almost had grown up they began training at doing work together. In the beginning they had a hard time getting anywhere. Ofcourse such young Cats are going to need to learn a lot of things along the way towards greatness. This is one of the things they learned early.

How to keep Cats busy with doing work
The cats sat down in a room together, looked at each other and talked for a while about what they are really good at. You probably already read the post about the team and know what their skills are. They got a lot of skills, and they made a plan to make sure all the skills are used as much of the time as possible. Wizzard Cat makes awesome Magic, Fixer Cat fixes a lot of things which appear to need fixing, Artist Cat makes much of the emotional Art and Expert Cat makes many great plans.
Working with this plan the whole Cat team made themselves very busy. They worked late nights, they made marvellous things and they had a lot of fun. They kept up this production for a long time since they knew it takes a long time to get any good result so they produced a lot of things.
After a few years the Cat team looked up and realized all the work they had done had resulted in nothing more useful than good times, practice and things. This is not a very useful result, what were the cats doing wrong?

Doing things rather than achieving goals
The Cat team had optimized the work effort for local optima. Keeping the team busy with doing what each Cat is really great at had caused them to fail at reaching the results with only can be met by Cats who help each other meet common objectives. This is an insidious trap which will catch unwary Cats who fail to maintain the discipline needed to keep the whole team focused on the most important objective, which for Lean and Mean Cat Teams is profitability.
By making sure all the cats are busy doing the things they are really good at doing they don't have time to learn about the things at which they suck. In this case they were sucking at setting priorities for the team and they failed to realize that what they were doing instead was waste.

The one trick which turned the Cats around
After realizing that the first few years of optimizing the work to do the wrong thing they turned the whole problem upside down. Instead of even worrying about what they are the best at they began figuring out what their product really needs right now, thereafter do that work together. They began testing their product against the userCats they were building it for and started to see that some things were decent, but most things were quite bad compared to what the Cats had though before they tested.
Now they were on to something. But there were some problems. Often they found that the product was full of bad magic which broke when the userCats tested it. Since Magic is what Wizard Cat does this made the other Cats scared that they would be unable to help Wizard Cat with fixing the broken Magic.

How the other Cats become assistant Wizards
The Cat Team of four cats, with only one Wizard Cat who needs to repair the broken Magic figured out what to do with the problem. The first bit is simple, the other Cats can make sure Wizard Cat is well informed about the symptoms of the broken Magic. The other cats in the team make sure there are userCats ready and waiting to test the new and improved Magic every time Wizard Cat finishes another spell. The other cats in the team can also help Wizard Cat with doing continuous exploratory testing and workshops to keep Wizard Cat really well informed about the value of the improved Magic.
When the problematic Magic is really badly broken the other Cats start talking to their friends to hear if any other Wizard Cats might have cast this spell successfully in the past. They dig up information and possibly seek out Greater Wizards who can help get the Magic in place. Since the other Cats sometimes can't do anything to be very helpful to Wizard Cat they begin spending more time together with Wizard Cat to learn how these Magic spells are cast. This makes the other Cats become low level Wizard Apprentices who will be better at gathering reagents which are more useful to Wizard Cat than what they otherwise usually produce.

Wizard Cat can not always be supported by the other Cats
Sometimes Wizard Cat also needs to be alone with his Spellcasting. At these times when the other Cats are unable to do anything else which helps Wizard Cat they have a few options. They can do some work on customer research and get better at understanding what type of product the market wants. They can do various planning experiments and test if they can come up with some neat solutions to the other problems the userCats have encountered while testing. They can even start sketching on something which is less important than the thing which Wizard Cat is working on. They can practice their skills at making tests or teaching each other about the deeper understandings of their methods.
They can even spend some time with the tools they use and build various little prototype things which in almost all cases are waste. But the practice is not waste so it has some kind of value. They can also do random things such as visiting their grandparents, have some coffee and get a bit of a tan. Someday in the future there will be room for Wizard Cat to enjoy these kinds of breaks when maybe Artist Cat gets stuck with needing to fix broken emotions in the product.
On a general level the cats found that even in these cases where one of the Cat Team Members gets really stuck with the most important piece of work it is better to avoid trying to produce other work with the rest of the team while the big hurdle is overcome. The really scary part is when the stuck cat is totally unable to know if the problem even can be solved. If such an unpredictable situation happens the Cats might have to back off and change their idea about the product. But first after trying to solve the problem.
Maybe next learning is how the Cats figured out to avoid Broken Magic...?

Saturday, October 24, 2009

The first hard Learning of the Cats

This post begins a journey of unpredictable length which describes things the Lean and Mean Cat Team has learned along the way towards achieving significance within the games market. We will begin with the hardest lesson first, then possibly move on to easier ones later.

A hard lesson for Expert Cat: Mastering Perspective
This is a lesson about communication and understanding where one of the biggest risks with your product really lies. Expert Cat has gone through a life long journey to develop an understanding for this type of situation so it will not be a nice and easy lesson to describe. But we shall give it a try, Expert cat is whispering his s33kritz into my ear as I try to write them down.
This is what Expert Cat looks like as he is trying to convey this message for me to write down.
As you can see he is sitting next to little blue dots and lines which say Node, Link and System. This might not seem like something which is a learning, but it is a pillar of the most fundamental learning he wants to tell you about.
He says that in the beginning he thought about the world as if it was made out of Nodes. That means things which has properties in themselves. It is an effective way of observing things to treat them as nodes and it makes life for the Expert Cat easier on the surface. He can describe them and point at them and people who listen to him has a decent chance to understand what he is talking about.
Links are a bit trickier to understand. They are the connections between nodes which describe that the nodes are interacting with each other somehow. This is a lot harder for Expert Cat to at first understand, even harder to make use of and almost hopeless to describe. How do you describe that the car and the road are connected through a link, you cant see it? Maybe the tires are a link, maybe it is the driver which wants to travel who is the link or maybe it is the engine which make the tires turn with force. Expert Cat almost goes crazy trying to describe this to other cats.
Systems are a bit easier to describe but harder to create. Expert Cat can lump a car, a road, an engine and a driver into a clump of things which together are a system. When he describes the whole system to other cats they intuitively understand that they could make some use out of the ability to drive along roads to places at speed and derive some type of value out of it.

When Expert Cat was young
As a youngster Expert Cat wanted to do great things for the other cats in the world and began working on creating things. Since back then he was only really able to understand the concept of Nodes he went about and made things. Sometimes his things caught a litle bit of interest among the other cats but nothing really worked. What is wrong with my things? - he though a bit sadly.
No one really wants things it seems. Well, actually there are situations where thing are wanted but those are special cases which Expert Cat will tell us about later in this story.

Expert Cat is trained by Master Cat
After making a series of failed things Expert Cat went out looking for a Master Cat who would become a great teacher. Master Cat began training Expert Cat at using different perspectives of looking at the world and introduced Expert Cat to the idea of systems. The things Expert Cat had been making were failing because they were not part of a system which the other cats were part of. The things which had partial success had by a chance become adopted by other cats as pieces of their personal systems which are hidden in the mystery of cat souls.
Master Cat spent years and years and mentored Expert Cat to learn how to observe systems. About ten years after meeting with Master Cat our Expert Cat emerged as a fully trained systems observer.

A trained Expert Cat
To make things successfully our Expert Cat learned to create links. Sometimes links demand the creation of Nodes, and sometimes links demand other things. The core understanding of Expert Cat was to see that things without links are dead weight, waste and useless creations in general.
The next problem for Expert Cat is to describe what a link is. This is a fundamentally tricky problem because they are always different in detail but similar in the abstract. Since the details always differ we can make one detailed example and try to move onwards from there.

Details of a Link
Lets us begin describing a link. We will describe the link of Eating. We can look at something and notice that it is getting Eaten. A good start. Expert Cat wants to create the link of Eating.
To create the link of Eating our Expert Cat needs to become dependant on two nodes. One node is a Cat, who Expert Cat thinks will be interested in eating. The second node is a Fish which Expert Cat thinks has suitable fit for the occasion.
This is a deep understanding of the Expert Cat. The value in the system of "Cat eats Fish" lies within the interactive process which is commonly called eating. The value of the fish which is not eaten can be considered "inventory" which according to lean is a risk. From now on when Expert Cat make things he defines his thing as the interaction between the nodes in the system. The ten years of training which Expert Cat has contained a few weeks of trying to understand the writings of Guru Cat Chris Crawford who says the trick to creating games lies with defining the design from the verbs in the design. Expert Cat believes this argument says the same thing with different words. Expert Cat believe verbs are quite useful when defining links.

Creating systems through Links, Nodes or Systems
While training with Master Cat our Expert Cat learned a few other things about systems. Different types of systems require different approaches towards their creation. To avoid needing to write far too much text we will narrow the problem down to two extremes.
The two extremes are described by a Guru Cat called Steve Blank. He uses a model which is a useful framework to dig at this problem. He uses the words "Customer Risk" on one end and "Technology Risk" on the other. Then there are things which has both...
On one extreme end we have a system where the risk is the functionality within the nodes. At this extreme end we find things such as a Fusion Reactor. If you can get the Fusion Reactor to work as it should then you have your value right there. Infinite power for a low cost. We can define this value as its node. If it works it will also have value for the other cats in the world.
On the other extreme we have the taste of Fish. Does the taste of the fish which Expert Cat is creating have any value on the market? The risk here is not that the Fish has a taste, or even if the fish exist, but rather if the taste causes the cat to eat. How does the cat eat the fish? Oh noez! This is so complicated Expert Cat is almost trembling at the notion of describing the situation.

To describe the problematic description as hypothesis
We need to use another lens to look at the problem to get a perspective which has a better chance of succeeding. To create the correct taste when cooking the fish our Expert Cat creates a hypothesis that says: "The fish tastes good enough to make another cat eat it." This puts the link to the test!
Now our Expert Cat can cook the fish with an inventive recipe and try to make another cat eat it. He can modulate his test and see if he can make another cat pay for the cooked fish, and see which of all the cats are willing to eat it or not eat it.
By successfully describing his fish recipe as the properties of eating he has obtained the all powerful insight into how changes to the recipe influence the value of the system. Wewt!

Ok, so what does this mean in practice?
Our Expert Cat understands how to differentiate customer risk versus technology risk. When Expert Cat joins a Mean and Lean Cat Team he knows that his team will be more or less suitable to handle the different types of risks. A team full of scientist and engineering wizard cats is likely to be suitable for taking on technical risk, which a team full of marketing Fixers and emotional Artist cats is suitable for taking on customer risk. A team which has a healthy balance of both is likely to take on challenges which contain both types of risk.

Kinds of risks for game creating cat teams
This is a pretty big system which practically is rather simple to understand.
Games with some Technical Risk:
  • MMORPG's
  • Next Gen AAA Console Games
Games with Customer Risk (Everything else):
  • Flash Games
  • Web based community Games
  • Facebook Games
  • Marketing Campaign Games
  • Indie Console Games
  • Indie PC Games
  • Oldskool Games
  • etc
Note that no games that the Expert Cat think is a game has purely Technical Risk. Defining a game Hypothesis as Nodes is thereby almost a guaranteed failure. Alright, Expert Cat jumped over a long series of arguments to reach that conclusion, but his time is running out and he wants to get out of here rather than keep on telling us the details of this story.
Farewell Expert cat, enjoy the sunshine and the Fish cooking! *waves*

Fixer Cat comes in to finish the lesson and says:
- Lean and Mean Cat Teams that use Agile or Scrum to create games need to learn how to define their Backlogs as links. If they fail to do this and instead base their work on creating nodes they become statistical death marches. However, if you create an MMORPG or a Next Gen AAA Console Title you can use a bit of both nodes and links to deal with technical risk.

Wednesday, October 21, 2009

Efficiency by Forced Iteration

This is a technique I apply on almost everything I do which has any expressive ambition. I'll call it Forced Iteration, I have not previously though of it as anything which has a name. After power-reading the stuff that Eric Reis and his crew is doing I realize it lies dangerously close to the idea of Continuous Deployment.

I have been messing around with the creation of usually unambitious artistic artifacts such as pieces of music, texts or even little experimental games. What I have realized over about twenty years of doing this is that the most effective way to improve the result is to publish it and make it available to some kind of living and breathing real audience. Even if it is only one other person in the audience this is vastly better than avoiding the publishing step.

What I do is that I first fiddle with the piece, this blog post is an example of such a piece. Then after I start losing tempo on the production of it I'll publish it. This causes me to feel a slight level of panic that I just published something which is total rubbish. The understanding that the rubbish is already out there and potentially being consumed by an end user triggers a reflex which makes me fire up a burst of energy which I spend by seeking out the worst flaws and I fix them just a few minutes after the publishing. Whew... the feeling of fixing the broken bits before anyone really saw them is actually quite good!

Now after the worst bits are fixed I will have a bit of breathing room which I use to judge the resulting piece of work more closely. This tends to spit out a new series of micro-iterations which hammer away at the lesser errors that I can see.

I am not a good writer, and I know that my English skills are quite lacking compared to what you'll see from a more engaging writer. This knowledge sets my level of ambition to be relatively low when it comes to making this blog great. Maybe someone who is smack dab in my target audience finds it comprehensible enough. Well, anyway...

The act of forcefully publishing the unfinished piece of work effectively speeds up the process of going from the idea of doing something until it meets the standards set by my level of ambition. I believe that I find this behaviour to be natural from having somewhat of a background as a live performing musician, even if it was a long time ago now. The live performing musician is in a constant state of streaming art directly to the audience. The reaction from the audience is the fuel which drives the engine of creation. And the idea that my audience will see the first iteration fuels the engine that creates the second, and so on it goes.

By using Forced Iteration this way the volume of fuel is maximized, at least for my type of engine. I know there are great artists who achieve greatness by going the other way around, but I have no idea of how they really do it, or how fast they really work.

Tuesday, October 20, 2009

The Symptom of Repeated Success

This is a post about something I have heard about happening from some distance. Organizations working with scrum or similar methodologies reach the conclusion that the methodology does not fit them. This is a hypothesis about why that tends to happen and a bit of reasoning around the problem.

As developers begin working with scrum or other agile methodologies it often appears as if they manage to achieve a productivity boost and gain features at a faster rate than they were used to. The teams really like this and find it to be a good practice. There is however one problem surfacing relatively often which present itself as a positive symptom of continuous and rapid success. However, behind this seemingly great facade hides a problem that seems eeringly common. The rapid increase in productivity and success is often a symptom of well... failure.
Now I'll have to explain, yay!
The problem is that the team is not achieving manageable failures. Every backlog item which comes from the product owner is successfully implemented and done within a sprint or two of work. Often each sprint contain several backlog items and the product takes on several new features in rapid succession. Now there is one of two possible states that you are in, one of these is more probable to be true and the other is likely closer to resembling a joyous pipe dream:
1: Awesome!!
  • The production is going on rails and creating fully tested and reliable user value with every backlog item which is started. The Product Owner is a domain expert in the field, has incredible insights in design and production techniques and is well connected with the market.
2: Hmm, what did the user feedback say again? Does that really match our Definition of Done? Or what does it really say?
  • The testing of user value does not inform the team about how much value they have been producing and they are developing features blindly.
If your team is experiencing this symptom of the repeated success you have a statistically troublesome scenario. The problem is that for the "Awesome!!" result to really occur you need to have one of the best Product Owners in the world. These guys are quite rare. You might also be part of an organization which is building an existing product within an existing market, this is the metaphorical equivalent of a Nuclear Power plant. The problem is known and the solution is known.
The user Values you develop are not known beforehand
It is quite likely that you are developing a product which aims for a niche market or a low-cost alternative within an existing market. In these cases your Product Owner will need to use the development team to run experiments against the market to find out how to handle the unknown factors. Be especially aware if you are making a new product in a new market, that means your hypothesis will be wrong almost all the time.
As any scientist will know you will not always validate all hypothesis as being true from their first experiments. This is where the failure of agile and scrum screams its loudest, at least from my perspective as Game Designer. I know that even the best of designers will only have a theoretical foundation which pre-validates a portion of the designs. A generous estimate says that you will be roughly correct maybe 70% of the time, but each feature contain several sub-hypothesis which in turn has about the same probability of success. This means that more than 20% of your Backlog will be dead wrong. And now I am being very nice about that number...
Features which are not valid user value is waste which is expensive to clean up
If you are part of an agile team which fails to invalidate the hypothesis within the Backlog be aware that you are most likely producing a huge design debt within the product you are working on. Not only are you failing to find the defects before they impact the user experience, but you are also failing to understand where the real user value actually reside and are thereby effectively torpedoing future design efforts aimed at cleaning up the debt.
Personally I would advice that the only reliable way to step out of this trap if you are sitting in it is to treat design debt just as you treat technical debt. Design Debt most commonly rears its ugly head as increased complexity within the user experience. Once there are many features of surmised value within the product which has been deployed it becomes quite difficult to separate the ones which have user value from the ones which don't. This is a type of debt which grows fast with compounding interests because the probability that any future backlog actually does anything good to the user value drops with the complexity of the already faulty design. This is well supported by how system complexity also increases exponentially with the number of components as neatly described by Metcalfe's Law.
The way out of Debt is slow and painful
You will need to slow down and begin to refactor the user value through effective measurement within the product. The more common attempt is to increase the volume of features which has the result of increasing the volume of produced waste.
I am not too sure about development teams which have had the ability to climb out of this type of mess. The most common exit strategy I hear people deploy is to package the failed product as "valuable experience" then starting over with a new vision, mostly to achieve the same experience next time. There are also other tricks of business magic which some have been able to perform where they can sell the work done to wealthy customers.
Beware of agile teams that do not report failures from the interpretation of relevant feedback from valid tests. These projects are quite likely to be creating delayed waste which have impact enough to be fatal to the project. When working on a particular backlog item ask yourself: "How would the statement that this feature is waste be defeated by a valid proof to the contrary?"
If the best answer you think you will get is a whole lot of opinions then you have a good reason to help improve the development process.

Thursday, October 15, 2009

The complete cat strategy guide for game production

This is a story about a group of agile cats with skills and a passion for games who build a game together. They met somewhere and founded:
One Lean and Mean cat machine which will be doing something cool and have an awesomely good time together while doing it. The cat team introduces themselves and writes witty descriptions about what they do on their Google Wave.
Fixer Cat: "I am like doing all that stuff that no one else does, making sure that nothing stops the other cats from doing awesome stuff. I am obsessive about development process, cycle time, kaizen, integrity and communication. Other IT projects might call me a combination of QA, Operations and maybe Producer."
Artist Cat: "Art is like a universe of symbolic language which has emotional resonance and communicate directly into the users brain through traditional data generation. I paint, I make sounds, I write texts, I make landscapes, labyrinths, hats, mice, animations, music, particles, movies and everything that you see and hear within the game. I got quite the education to know the theory, tools and practices of all these spiffy art forms."
Wizzard Cat: "Computers speak directly to my soul. Little impulses of electricity becomes living worlds full of cats and mice through the magic I perform. You might think the world is made out of things, I know it is made out of math, logic and process. Nothing within the game reaches the player unless I make it work. All the programming languages, technical platforms, rendering engines, deployment process, automated testing and the lot is stuff I have mastered. I am quite awesome."
Expert Cat: "Sun Tzu would be pwnd by me. If he wasn't dead already, I am still alive. I know marketing and how to position products. I know how to measure success and set goals which will be even more successful. I speak directly to the end users and learn what they desire. I communicate the markets desires to the team and workshop with the team until they prove they understand what the market wants. I test the products on the market and improve our results relentlessly. A game developer would call me a designer, maybe a non-traditional artist or a biz analyst. I also do stuff like interaction design and scripting when needed."
Our four cats are maybe not using the most conventional titles as the ones you might be familiar with. But keep in mind that these guys are mean and lean cats. They don't follow conventional rules. They make their own rules and play their own game to win.

Two kinds of players here, you know them already... In the world of cats they dont know they are a market. They just want to live their lives happily and in peace.

alternative text
The cats start working on a vision which causes a lot of half friendly cat fighting, including hissing and big fuzzy tails. Eventually cool cats reach agreement and begin with reality checking what they agreed upon. They keep running around in this loop until reality align with their concept. Or maybe it is the other way around, its difficult sometimes. If they fail they go back to the vision but these cats are so mean they only fail about half the time.

alternative text
The cat team takes a close look at the vision and how it is positioned on the market. They don't want to run into those nasty big competitors, some smaller competitors are quite ok however. They know what they are doing so they pick a spot which looks like it might have a few lonely cats without suitable and good games to play.

alternative text
Since the cat team has found its market position for a game they can start hammering out the concept. What kind of thing is this game that these other userCats are likely to want? They figure out what kind of symbolism might stimulate this audience into taking action. What kinds of goals the userCats are likely to find engaging. And they put these things into a list of priorities for production.
With priorities sitting on the wall as post-it notes they take the first one and they go out on the streets where userCats are hanging around waiting to be entertained. They talk to the userCats and carefully nudge up some information about the highest priority. Woot! This works! UserCats like this type of stuff... well sometimes at least. Quite often they have to run this loop a few times before userCats seem to provide the correct information. They might also learn new things about the competition here which needs to be taken into consideration. Sometimes they even encounter the wrong userCats and have to change them for others.

With a successfully developed list of priorities the cat team starts producing prototype products. They think this is what a Minimum Viable Product is about. They bring it to the userCats and see what happens when the user cats try it. In the beginning it does not work very good, but the mean and lean cat team knows how to repair their broken prototype and after a while the userCats start to appear rather engaged when testing it.
And there it is! The cat team has found resonance after a few attempts of prototyping. This is a key moment for the team to get a morale boost which will bring them forward towards cat nirvana.

alternative text
With the successful prototype to guide them the cat team goes into production.since they are so lean and mean they don't need any more cats for this, all they need is an even tighter relationship with the end userCats. So they pull userCats really close to the team to make sure they can test their product continuously against a useful feedback pipeline.
At this point the team starts investing a significant portion of their time into making sure that they can keep up a high speed through the loop. A lean and mean cat machine knows that the most important thing is to be able to react to feedback as fast as possible and they keep on making their reactions faster and faster for every circuit through the loop. The Wizzard protests loudly when the magic might be going kaboom in the future and the Expert stops the production and does a "5 whys" if the feedback from the userCats starts sounding like strange noises.


While running through the production loop the cat team is making these userCat loops, Daniel Cook named them STARS. Each feature consist of many of these loops and each iteration the cat team add value to these loops. Stimuli is the first thing the userCats encounter. The team makes sure all the stimuli in the game makes sense and fits the expectations of the userCats and sometimes they make sure that the userCats are positively surprised when moving through the STARS loop.
Daniel Cook is a hero for lean and mean cat teams.


Eventually the cat team will be successfully stringing the userCat loops together in some awesome patterns. As the Newbie user cat successfully runs through the loops the Newbie cat gets more and more engaged. The cat team is so good at this that the loops are whole and working. UserCats experience good pleasure and they don't burn out or feel confused and annoyed. As a userCat plays the first finished parts of the game it feels showers of dopamine in its brain which are produced when the nerve system extends its associations to better handle the Skills required by the game.

When the cat team picks up a new piece of the game to build they know that they are only in the beginning of a journey which will need a few round trips with the same piece. They are quite competent so they understand that trying to add another piece before the current one reaches the "market demand per feature threshold" is going to lead to a ton of waste in future production.
While working on making one function in the game good they methodically monitor the feedback from userCats for each iteration. They keep on iterating until there is statistically reliable proof that the purring is caused by the product and not something else.

alternative text

Oh noez! The cat team has run into a road block!
Regardless of how many times they iterate on a piece of the concept which aim towards the vision they just can't make the userCat purr from it. This is a tough spot to be in. Now they have to do a pivot. Such a lean and mean cat team is not very scared of this problem. They know that they have a solid core product developed which causes userCats to purr satisfyingly. To keep on progressing their product so they can get even more purring all they need to do is some analysis and observation.
The cat team steps back a bit and takes a close look at the market again. "Ok" they say, lets figure out where to move now. Should they abandon the project? Switch to some totally brand spanking new vision? Or ignore the feedback and release it anyway? No, instead they keep one paw firmly planted in their current vision, and prepare to take a step towards a new direction.
They adjust the aim of the vision a bit, keep the successfully developed userCat value, kill the remainder of the old backlog and define a new set of concept pieces which will lead to the new visionary point they find interesting.

Eventually the game does all of the things it should be doing and the userCats are excitedly running along its dopamine infused feedback loops, having a blast and feeling the luurve all around. The userCats realize that the lean and mean cat team made something that was just perfect for them and they send love letters and even a bit of money to the cat team.
The Cat Team are heroes in the world of the userCats and they know it. What the cat team will be doing next is a secret hidden within the future.