Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Is It Possible to Over-Communicate In Project?

    While explaining another thing which I thought was obvious for everyone in the team but appeared as not clearly communicated the question came back to me: is it possible to over-communicate in project? I dropped the question on Twitter and expected answers like “Hell no!” Or “Maybe it is possible but no one seen that yet.”

    Responses surprised me though. Author of Projects with People found problems of being too detailed for the audience or revealing facts too early. Well, what exactly does “too early” mean? When people already chatter on the subject at the water cooler is it too early? When managers finally become aware of chatter is it still too early? Do we have to wait until management is ready to communicate the fact (which is always too late)?

    Actually gossips are powerful and spread fast. The only way to cut them is bring official communication on the subject as soon as possible. Hopefully before gossiping is started. Which does mean early. Earlier than you’d think.

    Another thing is being too detailed. This can be considered as unnecessary or even clutter. Clutter is an issue raised by Danie Vermeulen. If something doesn’t bring added value it shouldn’t be communicated. If we kept this strict we could never post any technical message on project forum since there always would be someone who isn’t really interested which framework we’re going to use for dependency injection or how we prevent SQL injection and what the heck is the difference between these two. And how do you know what is a clutter for whom anyway.

    John Moore looks at the problem from different perspective – over-communication can be bad when it hurts morale. I must say I agree with the argument to some point. Some bad news isn’t necessarily related with people’s work (e.g. ongoing changes in business team on customer side) and can be due to change. Then keeping information for you may be a good idea. However if bad news is going to strike us either way the earlier means the better. One has to judge individually on each case.

    Although I don’t see easy way to deal with above issues they remain valid. Actually I can agree it is possible to over-communicate yet there’s no concrete border or clearly definable warning which yells “This email is too much! You’re over-communicating!” at you whenever you’re going to send unnecessary message.

    The best summary came from Lech who pointed that risk of over-communicating is lower than risk of under-communicating. I’d even say that much, much lower. How many projects with too extensive communication have you seen? One? Two? Personally I’ve seen none. On the other hand how many projects suffered because of insufficient communication? I’ve seen dozens of them.

    On general we still communicate too little. Yes, we can over-communicate from time to time but I accept the risk just for the sake of dealing a bit better with insufficient communication which is a real problem in our projects.

    How does it look like in your teams?

  • Shortcomings of Test Cases

    I’ve already told you that writing test cases is worth the effort. What I haven’t stressed are shortcomings of test cases.

    If you take time to prepare test cases you most likely do it for the reason and I guess not for “my manager will fire me if I don’t” one. You want to invite some organization to your testing and improve overall quality of the product at the end of the day. I don’t want to go deeper for motivations since it isn’t the point of this article.

    The thing you do is preparing some scenarios up front, definitely before you actually start testing. Generally the earlier the better but either way test cases are before test execution, that’s for sure. Basically when you prepare test cases you imagine how you’d like the application to be tested and you write it down. Do this, verify that, expect something other and proceed to the next step.

    Now what’s wrong with that?

    1. You suck at predicting how your users would use the products. We all do. Applications are built by developers who don’t even try to imagine how users will interact with software. Then they’re tested by quality engineers who are also far away from average users. Then they’re deployed by people who actually talk with users but can’t influence application development in almost any way. The whole process is driven by product managers whose job is to think about general concepts, not detailed usage flows. Who cares about usage scenarios then? Well, pretty much no one.

    2. Test cases are closed scenarios by definition. When designing test cases you don’t have “flow with your gut feeling” block at hand to put it in the diagram. You actually have to make it possible to verify test results thus you’re limited to some specific path – one among hundreds or thousands. This means you won’t go through the vast majority of cases yet you will decide whether a new feature works well or not.

    3. It’s not possible to have a complete set of test cases. A typical method which takes only an integer as an argument can be called in possibly 2^32 different ways which is basically infinity. If you add that you may need to call another function as a prerequisite you end up with a number which blows my head up. And we’re talking only about a single function, not about whole application. Test case is always a dramatic simplification in terms of possible usage scenarios.

    4. It’s easy to complete test cases and call it a day. Hey, after all test cases are for quality engineers, aren’t they? QA people should base their activities on test cases. Except they shouldn’t limit their work just to test cases. And you want it or not there’s always a bit of incentive to turn off your thinking and just follow the plan instead of going an extra mile. I’ve already said that a couple of times, but QA team is no place for follow-the-book people. Creativity is a key trait for QA engineers, yet we don’t live in an ideal world and you don’t have only the best and the most creative people in QA team, no matter what your company website says.

    With all these shortcomings I still strongly advise you to write test cases. You may try to do them as precise as possible, or you may just use general flows leaving some autonomy for testers but either way it will pay off. Especially if you understand where test cases fall short and find a way to deal with that using other tools.

  • What Is the Main Benefit of Writing Test Cases?

    Test cases are here for a long time. Used equally willingly by these who work with heavy-weight processes and those who choose the agile way. They can be stored in an appendix to documentation in BDUF (Big Design Up Front) project or be written on yellow cards along with user stories. Where’s their main value then?

    Think about the comparison: test cases for application functionality are the same as unit tests for application code. Except of one thing: it is way harder to write good and complete list of test cases. You may safely assume that’s impossible. This means the main value of test cases isn’t in covering full application functionality because you simply won’t achieve that, no matter how hard you try.

    Well, maybe it is a valuable tool for QA engineers? You know, they have some kind of walkthrough for testing sessions. Hm… show me quality engineers who prefer just to follow test cases instead of explore the application by themselves and I’ll tell who should be fired. Testing is such a creative task that there should be no place for follow-the-manual people in QA teams.

    OK, test cases don’t ensure completeness of tests and don’t help QA people much. So? Show me the money, as one of my customers used to say. Where’s value?

    The main benefit of test cases lies in the activity of writing them down. Or, to be more precise, in the process of thinking about them before they’re written down.

    Test case is not much more than short scenario of application usage. Sometimes pretty weird scenario but still. Unfortunately we often forget about this perspective. We tend think in terms of code or requirements and forget about the very basic thing – no class in the code and no requirement alone makes any sense for the end-user.

    Looking at application while being in end-user’s shoes benefits in two ways:

    – You find black holes of your design which aren’t covered with user stories, or requirements

    – You find usability issues since you see whole usage flow, not just a bunch of atomic functions

    The main value of writing unit tests is actually within the writing part.

  • Sure Shot Method to Improve Quality of Your Estimates

    That’s the old story: we suck at estimating. Our schedules tend to be wrong not only because there are unexpected issues but mostly because we underestimate effort needed to complete tasks. There’s one simple trick which allows improving quality of estimates. It’s simple. It’s reliable. It’s good. On the minus side you need some time to execute it.

    Split your tasks to small chunks.

    If a task lasts more than a couple of days it’s too big – split it. If it’s still too big – do it once again. Repeat. By the way that’s what agilists came with over years – initial size of user stories was intended to be a few weeks long, now it’s usually a few days at most.

    Why it works?

    • Smaller tasks are easier to process in our minds. As a result we understand better what we’re going to do. As a result we judge better what means are needed. As a result our estimates are better.

    • Smaller tasks limit uncertainty. In smaller room there are fewer places to hide. The fewer places to hide the fewer unpredicted issues there are. The fewer unpredicted issues the more exact are estimates.

    • Small tasks mean small estimates. A month-long task should be read as “pretty long but it’s hard to say exactly how long” task. Bigger numbers are just less precise. Splitting tasks ends up with smaller chunks of work. Small chunks of work end up with small-sized estimates. Small-sized estimates mean more precise estimates.

    As a bonus, during task-splitting exercise, you get better understanding what should be done and you early catch some problems which otherwise would appear much later and would be more costly to fix.

    And yes, the only thing you need is some time.

  • Great Performances in Failed Projects

    It’s always a difficult situation. The last project was late and I don’t mean a few days late. People did a very good job trying to rescue as much as they could but by the time you were in the half you knew they won’t make it on time. Then it comes to these difficult discussions.

    – The project was late.
    – But we couldn’t make it on time even though we were fully engaged. You know it.
    – You didn’t tell me that at the beginning. Then I suppose you thought we’d make it.
    – But it appeared to be different. We did everything by the book and it didn’t work.
    – The result is late. I can’t judge the effort with complete disconnection from the result.

    How to judge a project manager? Final effect was below expectations. Commitment on the other hand went way above expected level. Reasons for failure can be objectively justified. Or can’t they?

    Something went completely wrong. Maybe initial estimates were totally screwed, maybe it was unexpected issue which couldn’t be predicted, or maybe we didn’t have enough information about the way customer would act during implementation. Who should take responsibility?

    It is said that while success has many fathers failure is an orphan. There’s no easy answer, yet manager has to come with one.

    I tend to weigh more how people acted (their commitment and effort) than result (late delivery) but I treat them as interconnected measures. In other words great performer from failed project will get better feedback than underperformer from stunning-success-project. Here’s why:

    • I prefer to have committed team even when they don’t know yet how to deal well with the task. They’ll learn and outgrow average teams which already know how to do the job.

    • I wouldn’t like to encourage hyena-approach, when below-average performers try to join (already) successful projects. It harms team chemistry.

    • If there’s a failure I (as a manager) am responsible for it in the first place. If I did my job well me team would probably be closer to success.

    • Punishing for failure makes people play safe. Team will care more about keeping status quo than trying to improve things around.

    • Lack of appreciation for extraordinary commitment kills any future engagement. If I tried hard and no one saw it I won’t do that another time.

  • When Unit Testing Doesn’t Work

    Unit testing is such a nice idea. Developers create tests as they develop working software. Then they (tests, not developers) are executed during every build and it’s verified whether something hasn’t been broken over the way.

    Unfortunately unit tests very often doesn’t work well even when team formally boast they employ this practice. Why?

    1. Unit testing can’t be enforced. Yes, yes, I have heard about tools which measure code coverage. A problem is they tell you whether your code is covered but they don’t tell you with what. It can be covered with quality tests but odds are it is covered with a lot of crap generated just for the sake of achieving target code coverage. Remember you get what you measure.

    2. Writing unit tests is easy – maintaining them is a hard part. Consider you have your code and your tests perfectly working. Now you change something which breaks several tests. Is that a flaw in the code? Or maybe it was done on purpose and now you have to rethink and rewrite all broken tests. Heck lot work to do.

    3. Tests should be added all the time. When you find a bug which wasn’t caught by tests you already have you should add one which will do it in the future. And yes, that means more work on crappy maintenance tasks which is neither funny nor developing.

    4. It takes so long to run all unit tests. Sometimes tests are switched off because build process takes too long and they don’t have to be run each time, right? Well, wrong. They have to.

    5. Good unit test checks border condition while easy-to-write unit test exploits optimistic scenario. It’s pretty easy to write unit tests not using your mind at all. 2 plus 2 should be 4. Task completed. Case closed. How about using 0 or negative numbers or floats? Forget about them – too much work.

    6. Writing unit tests is boring. That’s not amusing or challenging algorithmic problem. That’s not cool hacking trick which you can show off with in front of your geeky friends. That’s not a new technology which gets a lot of buzz. It’s boring. People don’t like boring things. People tend to skip them.

    A key thing to have unit testing implemented well as a practice is right approach of developers. Unfortunately it can’t be trained. These lads and gals either believe unit testing helps them to create good software and they do their best to develop high quality unit tests or they just cover the app with some crap just to get proper code coverage result and pull the problem out of their ass.

    If you’re going to use unit test better be sure your people are the former. Other way around it’s not worth the effort.

  • Too Honest, Too Straightforward

    Vast majority of people working on software products contact their customers directly or indirectly. Yes, software developers included. Each time we do it we play a role of salespeople. Of course customers don’t see us making product presentations or negotiating prices. What do they see then?

    In my case answer is pretty easy since my attitude was commented several times in the past by my colleagues. I’m too honest and too straightforward. It’s definitely a mixed blessing if that’s a blessing at all.

    Talking about business is expected to be like old-school negotiations. Two parties sitting on two ends of the table trying to squeeze others as much as possible using all tricks they know. I hate it. I dream about this kind of discussion:

    – We can do it in 4 months. Here’s proposed schedule.
    – Are you sure phase 2 has to take so long?
    – Yes, since we have to develop integration module for external system. It could be probably a bit shorter if we had experts of that system available but we’ve worked with these guys before and there are always problems with them. If they won’t be an issue this time we should be able to deliver 2 weeks earlier but I wouldn’t bet.
    – OK. Another issue is the price. We won’t pay more than $100000. That’s our approved budget.
    – Let me think… We’d need to cut some functionality out of scope to make it a win-win. How about messaging module and these complex reports?
    – Um… we can let reports go but messaging module must stay. Deal?
    – Deal.

    Yes, I know, I am dreaming. Anyway I often try to bring this kind of approach to the table. Too often. You shouldn’t be surprised if you’re a customer and I ask you: “We plan to develop this product for you, does it makes any sense for you or is that just a brain dead idea?” I may also state: “This function would make both your and our lives easier, although I don’t believe they’d allow me to do it for free. Would you find some budget for the feature? I promise the price will be good.”

    On the side note, if you ever worked as a salesperson with me I know, you already hate me. I guess I must live with that.

    This approach may weaken negotiating position of my party. Sometimes it is considered as pretty harsh by customers since you occasionally don’t wrap up the truth with nice marketing blah-blah (“No, we won’t build and deploy complex telecommunication solution in a month”). That isn’t playing by the rules and from time to time people find it hard to deal with it at the beginning.

    However the thing I found out is that when a relation with the customer is already built they start to appreciate this attitude. Having an honest source of information on the other side is quite a valuable thing. Even when the guy is sometimes too honest and too straightforward.

    It doesn’t mean I’m totally happy with it. It definitely would be better if there were no scary ‘too’ word in the label they stick to my back.

    What kind of person are you? What do your customer see when they talk with you?

  • We All Are Salespeople

    A developer who sends an email to a customer to elucidate some details of proposed solution. He is a salesman.

    A project manager who goes on biweekly status meeting. She is a saleswoman too.

    A support engineer who answer for ticket submitted by one of clients. Guess what, he’s a salesman.

    A manager of software development team who receives escalation call from disappointed customer. Surprise, surprise, she’s a saleswoman.

    It doesn’t really sound as they all were salespeople but they are. Whenever we contact current or potential customers we all play role of salespeople at least a bit. It doesn’t mean we all should wear suits and have this marketing blah-blah talk ready to fire at the customer. It doesn’t mean we should all have minds set for thinking what product we could up-sell there. But it does mean people on the other side will evaluate our work as the part of current and future sale process.

    “We’ve done a project with them and we won’t do another.” Odds are that’s not the fault of sales representative alone, but developers or support engineers or project managers or all of them screwed their work. They failed at up-selling anything more, no matter how great their product could be.

    “We considered them as a company suitable for small projects only but they’ve proven their worth and now they’re one of our important vendors.” Oh, that wasn’t only the effort of key account manager responsible for that customer. Or was it?

    Even when our work isn’t seen directly by the customer it works that way. If a quality engineer does a perfectly good job hunting all the glitches it will be appreciated as an effort invested into high-quality. The company will be considered as one of these which delivers quality solutions (even when they aren’t always on time) and that’s pretty important factor when customer chooses a vendor. Or at least it should be.

    In this way or another we all help in selling our products. Most of the time we do that unconsciously but it doesn’t change our influence on setting new deals. We all are salespeople.

  • Role of Trust

    It is said that formal agreements are for bad times. As far as everything goes well we can forget about papers even when there are some of these. Either way it’s all about trust.

    A question: what happens when a subcontractor doesn’t do their work well? Do you take a signed papers and count forfeits? Or you trust them and you believe you can find a solution which is acceptable for both sides?

    What about relations with your bosses or your customers?

    Probably in each situation we have a different level of pain. Sometimes we’d use our formal weapons faster, sometimes we’d try to avoid that as long as possible. Where’s the difference? Trust. The more you trust someone the longer you’ll be talking with them as human with another human, not as lawyer with another lawyer.

    There are people who you don’t trust much, maybe you just don’t know them or they let you down before. When doing business with them you’d focus on formal agreements much. There are those who you don’t trust at all and you won’t do anything with them even if they’d pay you well. Of course there are also people who you trust much and their word weights even more than signed paper.

    Which kind of people do you work for now? Which kind would like to work for? If answers differ think about it.

  • Evidence Based Scheduling – One More Way to Improve Your Estimates

    Somehow my recent discussions are mostly about estimating. Last discussion on PM Clinic happens to be on the very same subject. It reminded me about great technique which can improve your software estimates. It is called Evidence Based Scheduling and I’ve learned this from Joel Spolsky’s article.

    The basic concept is pretty simple. Jack the Developer gets the task. Actually a bunch of them. He delivers his estimates basing on his guts. Estimates are most likely crappy but at the moment it doesn’t matter much. As Jack does his work he tracks how much time he really spends on the task. It may happen it takes two days instead of planned 4-hour effort. Velocity for this task is 0,25 and it goes to the history of Jack. When Jack’s history is long enough you can use it to judge how crappy his estimates are.

    Evidence Based Scheduling uses Monte Carlo simulation which takes some effort to calculate results. However Joel brings some good news here:

    “Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected. (…) This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}”

    After completing a dozen of tasks you can get pretty much insight which number you should use to multiply Jack’s estimates to get something close to reality. Of course full-blown simulation will probably lead to better results but you get the idea.

    There’s one more gem in Joel’s posting which is worth stressing:

    “Fix bugs as you find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because you don’t know what bugs you’re going to have. When bugs are found in new code, charge the time to the original task that you implemented incorrectly. This will help EBS predict the time it takes to get fully debugged code, not just working code.”

    I know it brings quite a lot of effort for Jack the Developer, since sometimes he fixes bugs really fast and accounting time spent on each bug fix to proper original task adds enough hassle to be reluctant to do so. However the ends are worth means this time.

    I strongly recommend you reading whole article as it delivers all the details about Evidence Based Scheduling.