Tag Archives: programmer

Flutter Dev Intern: One Month In

A month ago, I got accepted into a no-pay internship program volunteering as a Flutter programmer. It’s an interesting learning opportunity; I’m working with four other programmers from around the globe who personally don’t know each other, building native mobile apps on our free time. The program runs for six months, so I suppose I’ll be writing code with these guys until around April next year.

Team chat over at Discord 🙂

Even though there’s no pay and I spend time to help the team finish given app challenges, what I get in return is an insider experience working with a remote team as a programmer myself, instead of being a tester. That means I need to pitch in on the actual application code, and pitch in with a respectable level of quality. Although I already work with programmers on my day job, the communication dynamics is a bit different from what I encounter on a daily basis. It’s a good change of pace, and I’m somehow broadening my horizons a little.

Most of this past month’s challenge erred on the side of communication: talking to each other over at Discord, familiarizing ourselves with other people’s style of writing code, and gauging our roles within the team. It’s been fun so far. 🙂

Lessons from Kent Beck and Martin Fowler’s “Planning Extreme Programming”

The first edition of “Planning Extreme Programming” by Kent Beck and Martin Fowler was published about 18 years (that long) ago, and already it says so much about how planning for software projects can be done well. It talks about programmers and customers, their fears and frustrations, their rights and responsibilities, and putting all those knowledge into a planning style that can work for development teams. It doesn’t have to be labeled XP, but it does need to help people be focused, confident, and hopeful.

Here are some noteworthy lines from the book:

  • Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn’t even be happy if it did, because by the time the software gets there, the customers don’t want what was planned; they want something different.
  • We plan to ensure that we are always doing the most important thing left to do, to coordinate effectively with other people, and to respond quickly to unexpected events.
  • If you know you have a tight deadline, but you make a plan and the plans says you can make the deadline, then you’ll start on your first task with a sense of urgency but still working as well as possible. After all, you have enough time. This is exactly the behavior that is most likely to cause the plan to come true. Panic leads to fatigue, defects, and communication breakdowns.
  • Any software planning technique must try to create visibility, so everyone involved in the project can really see how far along a project is. This means that you need clear milestones, ones that cannot be fudged, and clearly represent progress. Milestones must also be things that everyone involved in the project, including the customer, can understand and learn to trust.
  • We need a planning style that
    • Preserves the programmer’s confidence that the plan is possible
    • Preserves the customer’s confidence that they are getting as much as they can
    • Costs as little to execute as possible (because we’ll be planning often, but nobody pays for plans; they pay for results)
  • If we are going to develop well, we must create a culture that makes it possible for programmers and customers to acknowledge their fears and accept their rights and responsibilities. Without such guarantees, we cannot be courageous. We huddle in fear behind fortress walls, building them ever stronger, adding ever more weight to the development processes we have adopted. We continually add cannonades and battlements, documents and reviews, procedures and sign-offs, moats with crocodiles, torture chambers, and huge pots of boiling oil. But when our fears are acknowledged and our rights are accepted, then we can be courageous. We can set goals that are hard to reach and collaborate to make those goals. We can tear down the structures that we built out of fear and that impeded us. We will have the courage to do only what is necessary and no more, to spend our time on what’s important rather than on protecting ourselves.
  • We use driving as a metaphor for developing software. Driving is not about pointing in one direction and holding to it; driving is about making lots of little course corrections. You don’t drive software development by getting your project pointed in the right direction (The Plan). You drive software development by seeing that you are drifting a little this way and steering a little that way. This way, that way, as long as you develop the software.
  • When you don’t have enough time you are out of luck. You can’t make more time. Not having enough time is a position of helplessness. And hopelessness breeds frustration, mistakes, burnout, and failure. Having too much to do, however, is a situation we all know. When you have too much to do you can prioritize and not do some things, reduce the size of some of the things you do, ask someone else to do some things. Having too much to do breeds hope. We may not like being there, but at least we know what to do.
  • Focusing on one or two iterations means that the programmers clearly need to know that stories are in the iteration they are currently working on. It’s also useful to know what’s in the next iteration. Beyond that the iteration allocation is not so useful. The real decider for how far in advance you should plan is the cost of keeping the plan up-to-date versus the benefit you get when you know that plans are inherently unstable. You have to honestly asses the value compared to the volatility of the plans.
  • Writing the stories is not the point. Communicating is the point. We’ve seen too many requirements documents that are written down but don’t involve communication.
  • We want to get a release to the customer as soon as possible. We want this release to be as valuable to the customer as possible. That way the customer will like us and keep feeding us cookies. So we give her the things she wants most. That way we can release quickly and the customer feels the benefit. Should everything go to pot at the end of the schedule, it’s okay, because the stories at risk are less important than the stories we have already completed. Even if we can’t release quickly, the customer will be happier if we do the most valuable things first. It shows we are listening, and really trying to solve her problems. It also may prompt the customer to go for an earlier release once she sees that value of what appears.
  • One of the worst things about software bugs is that they come with a strong element of blame (from the customer) and guilt (from the programmer). If only we’d tested more, if only you were competent programmers, there wouldn’t be these bugs. We’ve seen people screaming on news groups and managers banging on tables saying that no bugs are acceptable. All this emotion really screws up the process of dealing with bugs and hurts the key human relationships that are essential if software development is to work well.
  • We assume that the programmers are trying to do the most professional job they can. As part of this they will go to great lengths to eliminate bugs. But nobody can eliminate all of them. The customer has to trust that the programmers are working hard to reduce bugs, and can monitor the testing process to see that they are doing as much as they should.
  • For most software, however, we don’t actually want zero bugs. (Now there’s a statement that we guarantee will be used against us out of context.) Any defect, once it’s in there, takes time and effort to remove. That time and effort will take away from effort spent putting in features. So you have to decide which to do. Even when you know about a bug, someone has to decide whether you want to eliminate the bug or add another feature. Who decides? In our view it must be the customer. The customer has to make a business decision based on the cost of having the bug versus the value of having another feature – or the value of deploying now instead of waiting to reduce the bug count. (We would argue that this does not hold true for bugs that could be life-threatening. In that case we think the programmers have a duty to public safety that is far greater than their duty to the customer.) There are plenty of cases where the business decision is to have the feature instead.
  • All the planning techniques in the world, can’t save you if you forget that software is built by human beings. In the end keep the human beings focused, happy, and motivated and they will deliver.

Takeaways from Elisabeth Hendrickson’s “There’s Always A Duck”

Elisabeth Hendrickson’s book “There’s Always A Duck” has been around for a number of years but I have only been able to read it recently. Now I know what she meant about ducks. They’re literally about ducks, but also about people too. People are different, and yet we share similarities. We experience things, we communicate with each other, and we learn and get better because of those experiences. Her book tells us stories of her adventures and the lessons she’s discovered along the way, and it was nice to have had a glimpse of what she saw and felt with her encounters with software project teams and everyone involved.

Some takeaways:

  • The vast majority of programmers I have met are diligent, capable folk. They truly care about the quality of their work and want the software they produce to be useful. They work hard to make sure they are implementing the right features and writing solid code.
  • The next time you’re tempted to think of your programmers as idiots, incompetents, or quality hostile, remember that no matter what else they may be, they’re people first. Even if it seems like they’re hostile or incapable, it is far more likely that they are having a very human reaction to a particularly bad situation.
  • And before you blame someone else for a mistake, remember the last time you made one. I’ve made some real whopper mistakes in my time. We all have, whether or not we choose to admit them or even remember them. It may be that some programmers don’t care about users, but it’s more likely that bugs are honest mistakes made under difficult circumstances.
  • Even when we are speaking the same language and about the same thing, it’s hard enough to communicate.
  • The point wasn’t to catch every possible error. What seems to go wrong most often? What errors are difficult to see at first glance, and thus require concentration to prevent? What causes the most damage when it happens?
  • Janet doesn’t know anything about the ins and outs of creating software. She probably doesn’t want to know. She just wants to serve her customers well. And this software is not helping. Back at corporate, the Steering Committee, Requirements Analysts, Designers, Programmers and Testers are congratulating themselves on a solid release. What they don’t see is Janet’s pain. The feedback loop is broken. The team back at corporate has no mechanism to find out whether the software is any good. Oh, sure, they’ll detect catastrophic problems that cause servers to go down. But they won’t see the little things that cause long queues at the front desk of the hotel.
  • Testers naturally notice details. Not only do we notice, but we think about what we noticed, we attempt to interpret our observations to explain why things might be that way, we ask others if they noticed, we question our assumptions, and we poke and prod at things to see if our understanding is correct. We use our observations to inform us, and in doing so discover underlying causes and effects we otherwise might miss.
  • I sometimes fall into the trap of thinking that the first problem I see must be THE problem that needs to be solved. Perhaps the problem I spotted is indeed worth correcting, but I almost never manage to spot the true critical issue at first glance.
  • Both fear and excitement stem not from observable reality but rather from speculation. We are speculating that the bugs that we know about and have chosen not to fix are actually as unimportant to our users as they are to us. We are speculating that the fact we have not found any serious defects is because they don’t exist and not because we simply stopped looking. We are speculating that we knew what the users actually wanted in the first place. We are speculating that the tests we decided not to run wouldn’t have found anything interesting. We are speculating that the tests we did run told us something useful. None of it is real until it is in the hands of actual users. The experience those users report is reality. Everything else is speculation.
  • It’s not because Agile is about going faster. It’s because structuring our work so that we can ship a smaller set of capabilities sooner means that we can collapse that probability wave more often. We can avoid living in the land of speculation, fooling ourselves into thinking that the release is alive (or dead) based on belief rather than fact. In short, frequent delivery means we live in reality, not probability.
  • Hire the right people. If that means keeping a critical position on the team open longer than anticipated, so be it. It’s better to have an under- staffed team of highly motivated, talented, skilled people than a fully staffed but ineffective team. Remember that hiring mistakes often take only a few minutes to make, and months of wasted time to undo.
  • Listen. There are always signs when a project is in trouble: missed milestones, recurrent attitude problems, general confusion about the project. Sometimes these signs indicate a dysfunctional team, sometimes they’re just normal bumps along the road, and sometimes they are early warning signs of major problems. The only way to tell the difference is to listen carefully to what the team members have to say.
  • The best way to get people to accept change is to make it more fun, and more rewarding, to do things the new way.
  • Choose a path that takes you in the direction you want to go. Don’t choose a path simply because it takes you away from the swamp you want to avoid.