Monthly Archives: March 2020

Quote

On specific Agile (software development) traps

There’s much positive to be said about the benefits of Agile software development, and the shift of software development teams is one sign that many feel this way.

However, I think there are some limits to Agile, and this leads teams to fall into certain traps over and over. Indeed, the Wikipedia page highlights a common criticism of Agile, namely:

Lack of overall product design
A goal of agile software development is to focus more on producing working software and less on documentation. This is in contrast to waterfall models where the process is often highly controlled and minor changes to the system require significant revision of supporting documentation. However, this does not justify completely doing without any analysis or design at all. Failure to pay attention to design can cause a team to proceed rapidly at first but then to have significant rework required as they attempt to scale up the system. One of the key features of agile software development is that it is iterative. When done correctly design emerges as the system is developed and commonalities and opportunities for re-use are discovered.

Now, it’s not the case that teams either do design or not. But I have seen that there are a number of specific traps bigger that Agile teams fall into that arise from lack of design. These traps arise from making tactical or limited decisions outside of a larger framework or structure, which isn’t surprising since Agile followers are guided by the principles that the “best architectures, requirements, and designs emerge from self-organizing teams” and “working software is the primary measure of progress”. Unfortunately what I’ve seen that lead to is:

  • Poor middleware/database system decisions: with this trap, you get teams making a decision on deploying a specific middleware package or database system that will support the software development they are doing. However, while that may be great for the Dev, it may not be great for the Ops. If you have enough teams making tactical decisions, you may end up with a more complex system than is necessary and greater technical debt that you want. Once you get enough data into your database systems, trying to reverse the decision may result not result not only in new development and testing, but a small (or not so small) migration project as well.
  • Poor infrastructure decisions: likewise, with this Agile trap I have seen teams using IaaS pick different images to deploy their software onto. Like the database problem, developers may choose one operating system (e.g. Windows) over another (e.g. Debian) because they are comfortable with the former, even if the production environment is more of the latter. The result can be your organization ending up with multiple VMs with many different operating systems to support and thereby increasing the operational costs of the system.
  • Poor application framework decisions: I see less of this one, although it can happen where teams pick an assortment of application frameworks to use in creating their software, and as with middleware and infrastructure, this will drive up the support effort down the road.

Given these traps, I think the way to avoid them is to inject some specific design phases into the overall software development lifecycle. One way to do that is to revisit a software development lifecycle (see diagram below) used by practitioners at IBM and documented in places like this IBM redbook. It has a waterfall quality about it, but it doesn’t have to be limited to waterfall type projects. It can be highly iterative.

The lifecycle process is shown here (taken from the redbook):

 

GSMethod

The part of the lifecycle in the large box is iterative and not all that different from an agile sprint.  But here you take time to explicitly make design / architecture decisions before building  software. You continue to iterate while making important design decisions before building.

Now, before you start your iterative software development lifecycle, you should need to  make specific architectural decisions. You should make these specific decisions in the solution outline and macro design phase. For smaller teams, these two phases may blend into one. But it is here in solution outline and macro design where you make decisions that are fundamental to the overall solution.

For example, in solution outline you could make overall architectural decisions about the application architecture, the choice of infrastructure technology, what application frameworks are the target for the team. These overall architectural decisions guide the dev, test and ops teams in the future. You may also decide to park some of these decisions in order to do further discovery.  Macro design could be next, where each of the dev teams make certain design decisions about their technology choices before they proceed with their iterations. As they are building and deploying code, they can run into issues where they need to make further design decisions, either due to problems that arise or technology choices that have to finally be made: and this is where the micro design phase is useful.  Micro design decisions could be quickly made, or they may require spikes and proof of concepts before proceeding. Or there could be no decisions to be made at all.  The main thing is more design checkpoints are built into the development lifecycle, which can result in less complexity, less maintainability costs, and less technical debt down the road. What you lose in velocity you can make up in overall lower TCO (total cost of ownership).

There is a risks to this type of approach as well. For example, if the project gets hung up with trying to make design decisions instead of gather requirements and making working software. The key stakeholders need to be aware of this and push on the design teams to prevent that from happening. If anything, it can help the key stakeholders better understand the risks before getting too far down the road in terms of developing software. Overall I think the risks are worth it if it helps you avoid these common agile traps.

Highlights and Ramblings (a newsletter, as such)


Here’s a list of  random items I’ve been stashing away while working from home in this time of social distancing and the pandemic. Initially my goal was to create a newsletter, and perhaps I still will create one. Most of the newsletters I get, though, read like blog posts. That’s fine. But then why do I need to create a newsletter, when I can just post here. Plus, it will save you another thing to deal with in your inbox. Read when you have nothing else to read.

  1. Privacy: It’s worrying to me that as people try to adapt to social distancing, tech companies continue to do things poorly. I am thinking of Yelp signing up restaurants for GoFundMe, Zoom selling people’s data, and other tech companies ostensibly tracking sick people using cellphone data. It’s hard to think about things such as privacy abuse with all the fear of the pandemic, but it’s something to not lose track of.
  2. Food suppliers: Before the pandemic, it was a given that pickers would migrate to wherever crops were ripe and pick them, Perhaps not anymore. After this crisis, I think the world is going to need to reconsider so many people they took for granted before, be it food pickers, grocery store clerks, or delivery people. I hope this would mean they would be taken better care of. Maybe they will be. Or maybe the push for automation will come on even stronger. We will see soon enough.
  3. Leadership: Impressed to see that the grocer HEB in the US reached out to Chinese grocers to help them deal with the pandemic. Smart. A case study in good business leadership.
  4. Leadership, pt 2: Trump continues to be Trump: a crisis has not altered who he is or how he acts. All I can say is from my vantage point in Toronto that all three levels of government are being effective. It surprised me by how governments can spring to life during a crisis. I haven’t recalled such strong action since the start of the Great Recession. Not something to take for granted.
  5. Entertainment: As entertainers lost venues, it was heartening to see them take to Instagram and other platforms to perform for us. From singers playing new records to actors like Patrick Stewart reading sonnets was a balm.
  6. Scarcity: it was and is a shock to see sections of the grocery store still empty. Eventually it will return, and toilet paper will go back to being a loss leader versus a scarce product.
  7. Fear: lots of people seem anxious and down, understandably. The efforts of people to deal with that has been a comfort.
  8. Making things: Also, since I seem to have more time, I made a zine, did some painting, wrote some python code to process KML.  Blogged, of course.
  9. Food: Like many  people, I am baking and cooking. I mean, what else can you do? I miss restaurants and cafes and bookstores, though. They feed me with more than food.
  10. Other things: I thought this was a good piece on parenthood: https://www.theschooloflife.com/thebookoflife/the-task-of-parenthood/.  Nicholson Baker followed me on Twitter. Whenever I have interactions with prominent people, I think: oh, I should get serious now and not look the fool. But it doesn’t last for long.
Quote

Fun Fluorescent Sculpture because we could use some fun right about now

For more, check out:  Fluorescent Cacti and Leaf Sculptures by Nobel Truong from the great art site,  Colossal

Quote

How to clean with vinegar

Hey. You’re home. You feel: I might as well clean this place. Or maybe you want to get started on your spring cleaning. Good. Here’s a great list of how you can replace many of your kitchen cleaning products with just vinegar (and maybe a bit of water): 18 Places You Should Be Cleaning with Vinegar in Your Kitchen | Bon Appétit

Save money. Cut out those terrible chemicals. Learn some skills. 🙂

Quote

Are you a Canadian business wanting a primer on Canada’s COVID-19 Economic Response Plan?

Then check this out:  A quick guide for businesses navigating Canada’s COVID-19 Economic Response Plan | IT Business

Quote

How to get more cooperation from your kids regarding chores and morning activities

For people struggling with their kids while they work from home, this piece from The New York Times in 2018 might help. I think a lot depends on the personality of the child, but for some of you, it just might be the thing you need. In a nutshell, they did this:

We devised a personalized morning checklist for each child — with their input. And we created a breakfast menu and a lunch menu, just like the ones they give you in hotels. We’re talking the works here. For breakfast the children can have cereal, muffins, eggs however they want, smoothies. You name it! And the lunch menu is equally expansive. Each night the kids complete their menus for the next day’s breakfast and lunch.

How to whip your inbox into shape? Do this.

Are you one of those people who have hundreds if not thousands of emails in your inbox? Would you like to get down to Inbox Zero? Or Maybe Inbox 99? If so, try this approach:

1) First, for these next few steps, you will not open or read ANY emails. Just look at your inbox.
2) Second, sort your emails by sender. Go through and delete all emails you don’t need: email from people you don’t know or don’t care to respond to, emails from mailing lists (don’t worry, they will send you more), unsolicited email, spam, emails from your ex, etc. Delete delete delete. Read nothing.
3) Third, sort your emails by date. Delete all emails that are a year old or more. Can’t bear to do that for some reason? Then if you must, create a folder called “Attic” or “Basement” and put them there. (You will no more read them then you will look at the stuff you have stuffed in your real attic or basement either, but if it makes you feel better). Again, no reading: delete or file.
4) Ok, you have emails from the past year. Go through and sort them by subject. See all those emails with the same subject, or the “re: re:…”. Chances are you only need to keep one of those. Then delete the rest.
5) Now sort them again by date. Go to the oldest. For everyone you see, ask yourself: is this referring to something that’s over or resolved? If so, delete it or put it in the Attic folder.
6) Go through emails from newsletters. Open only to UNSUBSCRIBE. Otherwise delete.
7) Reminders for bills, etc. Write that down then file or delete.
8) Meetings that have past? Delete.

Now whatever emails you have, you can open. Try to skim them, but do this:
1) If it is an FYI, file or delete. Do NOT reply.
2) If someone did you a favor or a service, reply through non-email: a message, text or phone message even. Do not reply by email.
3) If it is a complex email, figure out what the ACTUAL request is. Write it down. Send them an email just with the request and your response; file or delete the other email.

Now the only emails you have left that are either from colleagues or family and friends. Deal with the most important ones first. Of those, make lists of what they are asking. Then consider whether to just deal with them the next time you see them. Whenever possible, do not reply via email.

By this point you should have alot less email. Look at you being all productive and efficient. Congrats! You did good.