Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Author: Pawel Brodzinski

  • What Motivates People

    Today I attended a training session where we were learning about motivation. I’ve heard pretty poor opinions about the session before, but I wouldn’t be me if I didn’t check by myself. And if you need to know these opinions were crap – training was pretty good.

    Anyway, we had a very small and very open group which was cool. I think I should thank here those who didn’t show up, since the session was planned for a bigger audience. The best thing about the group was each of us works in different team and we are on different levels in organizational structure. This means our perception of the organization itself and tools we have to motivate ourselves and our people differ vastly.

    This is kind of cool because otherwise we would barely have a chance to confront our points of view. And it appeared every single one of us pointed different things as our main motivators. This is basically the lesson I want to share with you. If you want to know what motivates people working for you, move your fat ass from your damn throne and learn what drives every individual in your team, instead of asking for universal recipes.

    Yes, you will hear all sorts of answers from “more money” up to “my cellar is cool actually; just don’t interrupt me when I’m in THE flow.” On a side note, money isn’t a tool you can use to motivate people.

    Motivation is a very individual thing. I remember sharing a really fat bonus with one of my former PMs after she completed one those hard core projects. Since we were getting on well I asked if that motivated her for further effort. The answer was “no, not at all.” I can’t say I was surprised much, since I’d moved my fat ass from my throne to learn what had driven my team. If you asked me why the fat bonus then, well, she’d still earned that money.

    Don’t expect simple answer for a question about motivating people. The subject is just too complex. And if you still believe there is a simple and universal solution for the problem you may want to reconsider predisposition to be a manager.

    In case you were curious my biggest motivators are learning opportunities and having things under control.

    You may also like other posts on motivation:

    http://blog.brodzinski.com/2007/10/money-as-motivator.html

  • The Kanban Story: Swarming

    If you’re into Kanban you probably have heard the term swarming. Actually chances are good you’ve heard the term despite your lack of interest in Kanban.

    What is swarming?

    In short swarming is all about getting more people to do the task than you’d get otherwise, in normal situation. An example: you have a bug which normally would be fixed by a single developer, but for some reason you have the whole team working on it. And you already have another question…

    Why, oh why?

    Why would you want people to swarm around a small task? Typically teams do this when they face either a blocker, which hampers whole team, or a very difficult problem, which is hardly solvable by a single person. Either way you get more people to move things further, which would be impossible or at least very difficult otherwise.

    Swarming in Kanban, part 1

    Up to this point swarming is something teams do intuitively at times. The reason why the term is mentioned so often in the context of Kanban is one of Kanban rules: limiting work in progress. Because in Kanban we want to have as few ongoing tasks as possible, yet as much as it still does make sense, we have limits for different stages of our process. And it when we hit the limit we treat it as a problem which we want to solve and we want to solve it fast. That’s why we swarm.

    Swarming in Kanban, part 2

    There is another thing which you may read about, which I call everyday swarming. Everyday swarming is done by teams which swarm by default, when no emergency situation happens. The reason standing behind this behavior is trying to make cycle time and/or lead time as short as possible thus flow of tasks very rapid and smooth. Oh, and you have fewer ongoing tasks then too, which means you have less work in progress, which means you have less waste, which means you are oh so lean.

    Our story

    I must admit I don’t really like the idea of everyday swarming. I mean cycle time is definitely shorter but I’m so sure about throughput. Flow is smoother but you kick in a lot of micro-switches when a few people need to integrate their work into one piece of code since they all have worked on a single feature. You also may invite some issues with version control this way since you’ll be working on the same chunks of code. For me the net weight of swarming by default is negative.

    Basically that’s why we avoid swarming whenever possible. When there is some serious problem to solve and standard approach is not enough we naturally help each other. One person after another joins the rescue team and this basically ends as swarming. But other than that we prefer to have only one person working on the task at the same time. Well, of course there are exceptions like discussing design or testing and bug-seeking/bug-fixing but these all are pretty natural things for any software development team. After all it would be pretty schizophrenic to discuss the design with oneself.

    It looks like we swarm as David Anderson initially proposed, despite ignoring David’s teachings when it comes to lead time. I think this is the most natural way of swarming. But of course you remember the rule to experiment like crazy, so you may want to try something different in your team.

    Read the rest of Kanban Story as well.

    http://blog.brodzinski.com/2009/10/kanban-story.html

  • People Are Lazy

    The other day I was asked to write an article for our company’s intranet portal. The first thing which came to my mind was “no one would read it.” Well, probably few people would but not many more.

    You might say I have a sad view of humanity, and you’d probably be right, but I kind of lost enthusiasm to systemic attempts to spread knowledge within organizations. And I mean here all things like intranet news sites, internal corporate blogs, knowledge bases, company magazines etc.

    In theory, as long as you have at least a few dozens of people on board, these things are great. They have no weak points. There are a couple of leaders who organize site/blog/magazine/you name it, then there is a group of producers who work on content and then there is a vast majority who consumes all the stuff.

    That’s the theory. In practice first two groups (leaders and producers) are rarely a problem. The problem is people don’t give a shit about your news site, blog, knowledge base and magazine. They couldn’t care less whether they might learn something from there. People just don’t want to learn.

    Scott Berkun recently shared his thought why the world is a mess in general (read not only the post, but comments too). His conclusions are that people don’t listen and don’t read either. This actually supports the theory I offer above – even if you take the effort to create a gem or two and drop it into your intranet portal no one would read, no one would notice.

    Actually not willing to learn, listen and read are just symptoms. And yes, there’s a single disease behind them all. People are lazy. They don’t learn because it’s easier to leave things as they are. They don’t read because skimming takes less effort. They don’t listen because trying to genuinely understand what other are saying is hard, much harder than just waiting for your turn to speak.

    Note, I don’t say I’m not lazy. If I have problems with motivating myself while working at home that’s exactly because I am. If I tend to procrastinate most of housekeeping tasks, like fixing the lamp or securing a shelf to a wall, the reason is the same. Scott may be no different by the way.

    Now, before you tell me that I’m over-generalizing, I know that. The same as you know that most people fit the picture above. When I look at statistics for recent articles on the intranet site I see that less than 10% of people in the organization read them. So when asked whether I would write an article on Kanban to be published there I wanted to answer with something like “I write about goddamn Kanban at least one every two weeks on my goddamn blog which you may find typing my goddamn name into goddamn Google. I did two goddamn presentations recently and sent goddamn links to two thirds of folks within the goddamn company. Shouldn’t that be enough for pretty much anyone here to find a goddamn article on goddamn Kanban?”

    But now when you ask, I will write the (goddamn) article. It is worth helping people even if just 10% of them care. And it might make me look less lazy too. You know, I just aspire to be in to 10% of population.

  • Internal Audit: Lessons Learned

    Last week we had an internal audit in our team. If you automatically think “ISO 9001” when you hear “internal audit” let me just state it had nothing to do with ISO. We have a few so called quality requirements in the company and every team should follow them but these aren’t anything like ISO procedures.

    The reason why I was interested how the audit would go is we work pretty differently than the rest of the organization so quality requirements aren’t really adjusted to our specifics. I was also curious how our non-standard process would look like in comparison to other teams.

    I caught a few things which are worth sharing.

    Small Features versus Big Features

    Our currency for functionality is MMF (Minimal Marketable Feature). MMF itself probably doesn’t tell you much and I know different teams use different sizes for MMFs. In our case average MMF can be coded by a single developer in about a week, so they are pretty small.

    On the other hand in other projects typical currency for functionality is requirement which is significantly bigger and, as such, less detailed. I’d say that on average it is few times bigger than MMF.

    Where’s the difference? I mean, besides the size itself. One very visible difference is we do significantly less paperwork. With features small enough that they can be easily analyzed and decomposed by product owner, developer and tester we don’t need to write low-level design documents or test cases or user stories. We can spend more time doing the real work instead of creating a pile of documents which tend to become outdated as soon as you hit the save button.

    Frequent Deployment versus Not-So-Frequent Deployment

    I guess there aren’t many teams which still treat deployment as one-time effort done at the end of project. But still, frequent deployment is a painful thing, especially when developers work in different team than QA engineers and QA engineers work in different team than release managers. An average project isn’t deployed biweekly. Not even close.

    On the contrary we deploy, on average, once every 9 days and I mean calendar days here. Of course it didn’t look like that from the very beginning and it cost us a bit to get there. I would say it took us about half a year to gain this pace.

    Where’s the difference? I could tell you about time-to-market, but it really depends on project whether you need time-to-market counted in days or months. The cool thing is somewhere else. With such a short cycle time we don’t have a temptation to incur technical debt. We don’t leave unfixed bugs. We just don’t. After all we might have been discussing about a single low priority bug, not a few dozens of them so the fixing cost would be so low that we don’t even start the discussion in the first place. Even if we hit a dead-end redoing the whole darn feature doesn’t take us a couple of months – it’s just a few days so it’s much easier to accept it.

    Everyone on the Same Page versus Formalized Process

    We’re small team and we’re co-located so we have fairly few communication issues. The process we follow is very simple and, what is even more important, crafted by our team. We all are at the same page.

    Most of the teams in the company follow more formalized process. There are different functional teams which are meant to cooperate, there are specific documents expected from each other by people working on projects etc. On the top of that there’s some office politics too and formalized process is used as a weapon.

    Where’s the difference? This one was pretty much a surprise for me, but it looks like our process appears as mature and effective even though it isn’t even recorded in any form. We just know what everyone should do. Whenever some obstacle appears on the way people naturally try to help each other as they see and understand what’s happening. And yes, I’m over the top just because no one forced me to write the process description down. On the other hand formalized process is often artificial for other teams who have to follow it and they sometimes focus on being compliant to the process (or fighting with it) instead of building software.

    What Does It Mean For You?

    I’m not trying to say here you should now automatically cut every feature you work on in half (at least), deploy three times more frequently than you do now and throw every procedure out. It would probably end with chaos, which your managers might have not appreciated.

    I’m not trying to say it was easy to get where we are now. It took great people, some experience, a lot of experimenting and enough time to get better at what we started doing. A year ago I would have hard time trying to point how our approach might be better than what you could find in the rest of the company.

    And I’m not trying to say you should read these advices in “this over that” manner known from Agile Manifesto. It’s not only our team which is pretty different than average team in the company but a product is also far from standard projects we build in organization so I compare pretty different environments. I wouldn’t even say that every single team in the company would benefit from implementing our approach, although a few of them definitely would.

    These are just things I learned while talking with Ola who audited our team (and many other teams in the company). For me these lessons weren’t obvious. I mean connection between frequent deployment and short time-to-market is pretty clear for anyone who understands what “deployment” and “time-to-market” means, but I’ve never really considered that very short production cycle may help to avoid technical debt too.

    And if you’re interested what the audit result was, I’d say it was pretty good. I mean, everyone likes to listen to some compliments from time to time, so we may want to ask for another audit soon.

  • The Kanban Story: Coarse-Grained Estimation

    Recently I told you what a screwed way we chose to measure lead time in our team. Unfortunately I’ve also promised to share some insight how we use lead times to get some (hopefully reliable) estimates. So here it goes.

    Simplifying things a bit (but only a bit) we measure development and deployment time and call it lead time (and don’t feel bad at all about that). So how do I answer to our customers when they ask me when something will be ready?

    That’s pretty easy. If we talk about a single feature and there is no other absolutely top priority task, I take a look at the board to track down a developer who will be first to complete his current task and discuss with him when he expects to finish it. Then I know when we can start working on the new, super-important feature ordered by the client. Then it’s enough to add two weeks (which is our average lead time) and make some effort to look oh, so tired as I’ve just completed such a difficult task of estimation. Oh, I need to tell the customer when they’re going to get the darn feature too, of course.

    This however happens pretty rarely. We try to keep our MMFs (Minimal Marketable Features) stick to their name which means they are usually small. This also means that described situations, when client wants just one feature from us, are pretty much non-existent. That’s why you might have noticed I didn’t take into consideration a size of a feature in described scenario. In the real life we usually talk about bigger pieces of functionality. What we do then is we split the scope into small MMFs and then use two magic parameters to get our result.

    One of parameters you already know – it is an average lead time. However there’s one more needed. It takes 13 days for the feature to get from the left to the right side of the board, but how many features are on the board at the same time? I took a crystal orb and it told me that on average we have 4,5 MMFs on the board. OK, I actually did a simple analysis of a longer period of time checking our completed MMFs and I got this result, but doesn’t a crystal orb sound so much better?

    Now, the trick I call math. On average we can do 4,5 MMFs in 13 days. Since I have, let’s say, 10 features on my plate I have to queue them. If I worked with iterations it would take 2,2 iterations (10/4,5) which basically means 3 iterations. But since we don’t use time-boxing I can use 2,2 and multiply it by 13 days of my lead time and get something about 30 days. Now I don’t start with empty board so I have to add some time to allow my team to finish current tasks. On average it would be half of lead time so we should be ready in, say, 37 days.

    And yes, this is rough estimate so I’d probably go with 40 days to avoid being blamed for delivering estimate which looked precise (37 looks very precise) but was just coarse-grained estimate.

    That’s basically what I went through before telling my CEO we’re going to complete management site for the product we work on in 3 months. Well, actually I didn’t told him yet, but 3 months there are. No less, no more.

    Although this post may look as it was loosely coupled with the Kanban Story it is definitely belongs there. So go, read the whole story.

  • The Kanban Story: Measuring Lead Time

    During AgileCE conference I had a discussion with Robert Dempsey about measuring lead time. I never really thought much about the way we count lead time in our team and talk with Robert triggered some doubts.

    What We Measure

    As you already know on our Kanban board we have backlog, todo queue, several steps describing our development and deployment process and finally done station.

    OK, so when do we stamp the starting date for the feature? We do it when the card goes from todo queue into design station, which is the very first column in our development process.

    When do we stamp ending date then? You may take your best guess and um… you’ll be wrong. No, not when the sticky note is moved to done column. Actually we mark ending date when a feature makes its way to live column which is third station from the right.

    And this is different from what you may have heard from Kanban gurus out there. Don’t blame me, I’ve already told you thought-leaders don’t know it all.

    What we measure is time which passes before we start actual work on feature to the moment it goes live.

    What We Don’t Measure

    What is left behind then? First and the most important thing is the time feature spends in todo queue waiting for some developer to become free and start working on it. If you were trained by the father of Kanban – David Anderson – you’ve probably heard something different but stay with me, I have a good explanation. Or so I guess.

    Another thing which is left outside is the last part of our process. There is documentation station where we (surprise, surprise) update documentation. This is done after pushing new version to production.

    It looks like we cut something on both ends to make our lead times look better, doesn’t it? Anyway what we gather as lead time doesn’t really describe time which passes from the moment of decision to build the feature to the moment it is done-done. Thus another question arises.

    Why, Oh Why?

    The way we measure lead time came in natural way but chat with Robert forced me to make some explanation up to justify our practice.

    Time Spent in Todo Queue

    We left time spent in todo queue out basically because content of this station is changing pretty often. Sometimes feature lives there just for a day or so just to go back to backlog when priorities change. And believe me they do change every now and then. Sometimes a feature stays in todo queue for a longer time as it is always pushed to the second or third place because, well, priorities change.

    There is another reason too. The basic reasoning for adding time spent in todo queue to lead time is that you should be able to tell your customer how long it would take from the day 0 (when they tell you they want the feature) to the moment they get it in production. It is pretty rare case when developers are able to start working on a new feature immediately so it is natural that some delay will appear when feature is waiting for a free developer.

    I’m not convinced though. Actually very much depends on additional circumstances. The feature the client is asking for may be the only high priority thing to do at the moment but it is pretty unlikely. If the client asks just for one feature lead time will be different than if they asked about a list of ten features. If you have limit of 3 in todo queue you would need to put 7 features in backlog anyway and time they spend in backlog won’t be measured.

    If you have a few clients and you need to balance your workload among them it becomes even more complicated since product owner (or whoever is your priority setter) has to decide which feature can be put on the top of the todo queue, which can occupy second or third place and which has to go into backlog.

    Basically in any situation but the simplest measuring time spent in todo queue wouldn’t help us much and that’s why we decided to exclude it from lead time.

    Time Spent on Documentation

    With documentation the situation is a bit different. Documentation isn’t a real part of our product. We create it for our internal reasons – to make life of our sys admin easier and to avoid problems if he was hit by the bus. This means that, from client perspective, our product is complete as soon as it goes live. Even though we have to do some housekeeping later it doesn’t affect our ability to deliver.

    Theoretically it might be a problem if documentation phase would be time-consuming and would steal time we’d prefer to spend for something else, namely deployment or testing. However looking at the past in the team it isn’t a problem so we may safely throw documentation out of lead time.

    The next thing is using lead time to create some estimates but that’s the subject for another post.

    If you liked this post you should like the whole Kanban Story too.

  • Why We Don’t Write Test Cases Anymore

    Almost a year ago I shared an advice to use test cases. Not because they are crucial during testing or dramatically improve the quality of the product (they are not), but because of value you get when you create test cases.

    A confession (and yes, you’d guess it anyway if you read the title): we don’t write test cases anymore.

    We stopped using them and the reason isn’t on the list of shortcomings of test cases. Actually I was aware of these shortcomings a year ago and I were all “test cases are great” anyway. What have changed then?

    We dropped test cases as a side effect of implementing Kanban, but you can perfectly use both if you like. In our case one of effects of switching to Kanban was making our pieces of functionality pushed (pulled actually) to development smaller. Before the switch we had pretty big features which were split into several (8-15) detailed user stories. After the switch we have much smaller features which would make 2 or 3 detailed user stories if we didn’t drop writing user stories at all.

    And the reason for making features smaller was simple – smaller features, smoother and more flexible workflow.

    Initially we were connecting test cases to features, not user stories. It was so because pretty often one testing flow was going through a few different user stories. I told you they were detailed. When standard feature-size went down we realized there’s much less value in preparing test cases.

    Once again: main value of creating test cases is thinking about specific usage scenarios, looking for places forgotten during design. The more complex feature the bigger are chances there is something screwed up. With small features test cases lost much of their value for us since most problems we were able to locate instantly and fix problems without additional technique. And yet the effort needed to create and maintain test cases was still significant. So we dropped the practice.

    It looks like my advice is: make your features smaller, and then you’ll be able to drop user stories and test cases. And I must say it does make sense, at least for me. What do you think?

  • Which Engineering Practices You Should Use

    XP is a “software development through the eyes of an engineer” kind of methodology. It focuses heavily on engineering practices.

    On contrary, neither Scrum nor Kanban seems to care much about best software development practices. But wait, if you read about Kanban a bit you’ll quickly find an advice to focus on your engineering practices too as Kanban (or Scrum) alone is not enough.

    Actually I can’t recall any project management approach which says “when it comes to code, do whatever – this whole programming thing doesn’t really matter.”

    So we’re back here again – a set of best software development practices is important. Yet, there is plenty of them, how to choose the right ones?

    You may choose a set of tools you believe are most valuable. However if you don’t have comfort of choosing toolbox first and then looking for people who are familiar with tools (or at least willing to learn how to wield them) you’re likely to fail.

    Every change is difficult and developers tend to be pretty stubborn. Yes, they will do this whole code review if they really have to, what a big deal anyway, but don’t expect to get decent results unless developers believe it is a valuable technique. They will hate it probably as much as filling data in time tracking app, which isn’t even close to what you wanted to achieve, right?

    And this brings me to another approach: let engineers choose which engineering practices they want to employ. Let them argue. Let them look for consensus. Help them in facilitating discussion if it’s necessary but don’t enforce any specific technique. Throw in a few ideas but if they don’t catch up don’t try to use your magic power: “I can force you to do so.” If you’re a team leader or (even worse) a manager it’s not you who will be doing this darn thing every single day for next couple of years so just shut up, OK?

    The best set of engineering practices is the one which will be adopted by engineers. And yes, this means it will be changing over time. The more mature the team is the more practices people are able to adopt.

    The same rule works in other areas too. Product management? Well, don’t you have a product owner or something? Let her decide. Testing procedures? Shouldn’t you agree to whatever your QA guys want?

    When it comes to discussion on standards a manager should take a step back and let a decision to be made by people who will be affected.

    There’s one trick here however. If you happen to work with inexperienced or just average people the consensus may be “let’s just hack some code instead of wasting time on this stuff, we’re Cowboy Coding Wizards and nothing can beat our code.” But then you have a bigger problem than deciding which of best practices your team would use. You better start to evangelize your team a bit or look for another job, whichever looks easier.

    There’s another trick too. What to do if you have hundreds or thousands of developers? Well, different toolboxes should emerge in different teams and it would be pretty stupid to try to standardize all of them. “What if nothing emerges despite a multiple teams working on software development?” you may ask. Well, running away while screaming would be a pretty good option there I guess.

    You didn’t really expect to see here The Big List of the Best Engineering Practices Every Team Should Adopt, do you?

  • Trust Isn’t Measurable

    I have a question for you. And yes this is one of this dumb black-or-white questions which don’t take into consideration the world is just gray.

    If you had to choose a vendor among the one which you trust more and the one which can be paid less what would be your choice?

    I pretty much expect most of us would say we would choose the trusted one. However what I see everyday people do the opposite. They tend to base on a price heavily.

    Of course the question is flawed since it assumes that everything else is equal which is never true. However the message I’m trying to send here is that, despite what we say, we tend to make our decision basing on things we are able to measure. We can easily say this offer is $10000 cheaper than the other; we can easily say that this schedule is a month shorter than that etc.

    Unfortunately we can’t say that our trust for the company A is at 5 and for the company B is at 7 (whatever 5 and 7 means). Personally I would probably be able to state that I trust one vendor somewhat more than another but it would be totally personal and your opinion about these companies will likely to differ much. And even if we both agreed we would have hard time trying to describe what exactly “somewhat more trust” means and why it is worth ten thousands more to our decision-makers.

    And that’s why I’m not really surprised we tend to act differently than we use to say we’d do. The reason is simple.

    Trust isn’t measurable.

    Every time we face the task to compare few things we tend to base on aspects we can measure and that’s where trust falls short.

    Luckily enough sometimes we are able to forget about this whole comparison thing and decide we just want to do business with a trusted partner. Even if they would be more expensive if we took an effort to compare their offer to others, which we don’t do anyway because, well, we decided to go with these trusted folks in the first place.

    With trust in place business relationships tend to be significantly better. And yes, I can explain it. More trust means more transparency. More transparency means more information shared. More information shared means better knowledge about the situation. Better knowledge about the situation means better planning. Better planning means better outcomes. And better outcomes usually strengthen business relationship.

    I would choose trust over price. If I stated I’d do it every single time I would lie (I did actually) but when it’s my own call or I’m strong enough to defend the decision trust trumps the price.

  • Should You Encourage People to Learn?

    A very interesting discussion followed one of my recent posts about people not willing to learn. There were a few different threads there but the one brought by David Moran is definitely worth its own post.

    David pointed it is manager’s responsibility to create learning opportunities and incentives for people to exploit them.

    At the first thought I wanted to agree with that. But after a while I started going through different teams and people I worked with. I recalled multiple situations when opportunities were just waiting but somehow barely anyone was willing to exploit them. The rest preferred to do nothing.

    I believe most of the time it is not the lack of opportunities which is a problem but lack of will. Now the question is: whether a manager or a leader should create incentives for people around? If so what kind of incentives should it be?

    First of all, I don’t believe in all kinds of extrinsic incentives which are aimed to encourage people to learn. If you set a certification or exam passed as a prerequisite for someone to be promoted people would get certification just to get promotion. They won’t treat it as a chance to learn but as one of tasks on ‘getting promoted’ checklist. You get what you measure. If you measure a number of certificates you will get a lot of these.

    The results are even worse when you create a negative incentive, i.e. you don’t get bonus money (you’d earned) unless you submit your monthly article to knowledge base (seen that). What you get there in majority of cases is just a load of crap which looks a bit like knowledge base article. After all no one will read it anyway so why bother?

    What options do you have then? Well, you can simply talk with people encouraging them to learn. “You may find this conference interesting.” “Taking language course would be a great for you.” “I’d appreciate that certification.” Unfortunately it usually works with people who are self-learners in the first place and don’t really need an incentive – the opportunity is enough (and they probably find opportunities by themselves anyway). The rest will most likely agree with you but will still do nothing.

    You may of course promote self-learners over the rest and most of us probably do it since people who feel an urge to learn are generally considered as great professionals. Unfortunately this mechanism isn’t completely obvious and is pretty hard to measure (how would you measure self-learning attitude?) so its educational value is close to zero.

    Coming back to the point, I don’t think that it is manager’s responsibility to build incentives for people to learn. I think the role of a leader ends somewhere between supporting everyone’s efforts to learn and creating opportunities. Besides if learning is enforced it won’t build any significant value.

    And yes, it is manager’s role to have a knowledgeable and ever-learning team but forcing people to learn is neither the only nor the best available approach.