Certainly, no one is asking you to reinvent the wheel. At the same time, you shouldn’t take its existence for granted.

Industry veteran and offshoot CS educator Kent C. Dodds says as much here, in this short speech he gave in 2018 a system he called “Testing from the Wheel”.

Dodds describes the following strategy for testing code: Test a lot, test always, test from the bottom-up (starting with unit testing and finishing with high-level UI testing), and never forget to test.

Consider this. The wheel may have already been invented, but can you trust it without playing around with it yourself?

I’ll only test code which I know isn’t up-to-snuff. Anything else isn’t worth my time.

Consider this: as Dodd points out, oftentimes the lens by which we regard our tests with is forced to change, along with our understanding of the product as yet written. Whether by an honest error in the specifications or new priorities on behalf of the intended recipient, code changes fast. It makes sense, then, that our ability to pivot to those changes needs to be just as adaptive and reactive.

When we consider the wheel, whether as part of a bottom-up test strategy as Dodd suggests or in our own deliberations, we should never forget the lesson it teaches us. As engineers, we must foster a sense of perennial inquiry which leads us to reexamine the most innocuous things in life. As developers, we must deliver product that is not only technically sound but financially so as well, which means expediting our review and test processes to a maximum. Every wheel, every time, everywhere.

Consider this: the vehicle that propels us all throughout life uses many wheels. And so many such wheels are taken for granted.

But if not the wheel, then what about Phlebas? Consider Phlebas.

Iain M. Banks’ silent, yet impassionate plea for his readers to understand hubris and its lingering aftereffects—not only on the soul, but on the character and legacy of a person—should ring especially clear and true with programmers of all walks. Sometimes we create something bold and are enamored by our own work, when really we should be questioning ourselves for our own good.

Surely this code is already really good. I don’t think I need to test it.

Like Pygmalion, we can ofttimes delude ourselves into thinking our code is so well-written that it needs no review. But in doing so, we endanger the stability of our own codebase and any future additions. Always test. Always, every time, everywhere.

Like the wanderer traveling through the senseless, meandering Waste Land of Eliot’s embattled imagination. Like Banks’ non-eponymous stand-in for Phlebas himself, though “he be a thousand years in his grave.” The lesson of self-agency is not one of jubilation, but rather a cautionary tale of despair. Because the people who possess it are destined to become their own undoing. Like us, if we don’t learn to know any better. If we don’t strive to challenge and doubt ourselves. If we don’t stop to consider the wheel.

Whether the most junior DevOps specialist or the most senior CTO, consider the wheel, simple and true, and sometimes deserving of your full consideration in spite of that.

Sometimes, it’s better to understand how to come back from success than dealing with having too much of it.

Kevin N.

From the blog CS-443 – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

Today’s article, “Recommendations for fostering DevOps culture”, comes from the Azure Well-Architected Framework. You can find it here.

Following up on my previous two articles on the failure of Spotify model and an exercise to attempt to salvage some part of said model, I decided to read an article from Microsoft on how to best implement DevOps. Their suggestion? Start with the team culture.

What is it about?

This article lays a whole bunch of best-practices for creating a successful, productive, and well-managed team structure, in accordance with Azure’s Well-Architected Framework.

What did I learn?

That more than anything else, culture is what separates a computer hobbyist from a professional engineer. It’s not enough to simply be individually passionate; you have to be part of a team structure that allows your passion to directly contribute to the success of the team, and for you to be similarly inspired by your own teammates’ contributions.

What was most surprising to me?

That these are “common sense” principles. I think a lot of people, especially in the corporate world, have a particularly hierarchical idea of team structure. I’m sure we’ve all had one boss who’s been far too interested in holding pulse checks, team meetings, and debriefs than they were in actually letting their employees do their work.

Even so, the fact that many of the WAF’s principles not only make sense but make good sense seems to be a credit to how well-thought out they are. Rather than forcing the issue of collaborations through meetings, for example, it says to allow for collaboration to occur in small spaces between workers, so that the process of ideating comes naturally at its own pace.

What are my take-aways?

• Encourage interrelatedness as opposed to interdependence.
• Use effective team charting software, i.e. Jira. (See last week’s article.)
• Embrace continuous improvement, continuous integration, and continuous development wholeheartedly.

Kevin N.

From the blog CS-443 – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

You ever think about how being a software engineer is kind of like working in a factory?

I mean that quite literally. Especially here in Massachusetts, where primo office space quite frequently gets hollowed out of old textile mills. (The old David Clark building by the intermodal port, and a slew of defense contractors in Cambridge-Braintree, my old workplace included, come to mind.)

In some ways, the comparison isn’t unmerited. I don’t think it’s far-fetched to say that the focus of industry is to deliver product.

Okay, but how?

Last week, I wrote about the failure of the Spotify model — specifically, their implementation of large-scale Agile-based DevOps. You can read more about that here.

The impetus for this week’s blog is ‘what-if’; if, instead of Spotify’s focus on large-scale Agile integration, we approached DevOps (in a general sense) from the bottom-up, with a clear emphasis on software tools and freeform, ad-hoc team structure. What can we use, what can we do to effect a stable and logical working environment?

Just one quick disclaimer: this is bound to be biased, especially in terms of what I’ve seen work in industry. Small, tight-knit teams and relatively flat hierarchies. This won’t work for every situation or circumstance — and by sidestepping the issue of Agile at scale, I feel like I’m ignoring the issues endemic to Spotify’s structure.

Still, I figure it’s worth a shot.

Issue Hub: Atlassian Jira

The first thing we’ll need is an issue tracker. Atlassian doesn’t do a very good job at marketing its products to the non-corporate world, but it’s very likely that almost everyone reading this post has used an Atlassian product at some point or another: Trello, Bitbucket, and, best of them all, Jira. Think of it as a team whiteboard, where we can report on bugs, update our wikis, and view the overall health of our build, all within one web server.

Version Control: Subversion

Subversion is going to be our version control software. Although this doesn’t have all of the downstream merging capability of Git, its centralized nature actually works to our benefit; the specific combination of Jenkins, Jira, and SVN form a tightly-knit build ecosystem, as we will see.

CI Automation: Jenkins

Jenkins is a continuous integration (CI) and build automation utility which will run health checks on downstream builds before they’re committed to the nightly build, and then to the master build overnight. We’ll implement all of our tests and sanity checks within it, to ensure that no one pushes bad code. If, by some miracle, something does get through, we can revert those changes—another handy feature.

How does this work?

SVN repo → Jenkins (throughout-day staging, then end-of-day nightly build, then overnight master) → Jira (for reports and long-term progress tracking).

Does this all work?

In a word, hopefully. The social contract between you and a team of four or five people is much simpler to fulfill than that of you and the Tribe in the Spotify model. (You only have to track the work of several people, as opposed to almost everyone on-campus with the Tribal model).

There are commitments and onboarding requirements to a system like this, too, as there was with the Tribal model, but they’re not as pronounced, especially since we aren’t scaling our structure beyond this one team.

I think what is especially true of the workplace is that no two teams are alike, and it’s kind of crazy to assume that they are, which is exactly what Spotify did. How is it worthwhile to tell people who they should be working with, instead of letting them figure that out on their own?

Rather, by placing constraints on how the work is done (which is what we’re doing here—the emphasis on software as opposed to structure) we can get better results by letting people figure out how to get from Point A to Point B, assuming we properly define both A and B.

Between last week and now: a lot of thoughts to digest.

Kevin N.

From the blog CS-443 – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

Something I think about quite frequently is how engineers seem to live in a world of their own creation.

No, really: open an app—look at a website—play a game of (virtual) cards. The designers of these programs each had their own take on how these experiences ought to be represented; the visual language, the information density, the flow from one experiential strand to another. These aren’t happenstance—they’re conscious decisions about how to approach a design.

But engineering is a bit like collectively building a diorama. Things look well enough in miniature, but the problems—with the product, and with the people working on it—become more clear the more you scale upwards.

This problem isn’t new, or all that far-fetched: engineers are specialists, and they’re good at what they do. Put two engineers together, and you’ve got yourself a crowd. Put three, and you have a quorum. Put a whole team of engineers on the same problem, and now you have a new problem.

(If you’ve ever wondered what happens when an engineer fears of being obsolesced out of their job, it’s not hard to imagine. It rhymes with “reductoring.” Alternatively, imagine a small, innocent codebase exploding into a million pieces, and you get the idea.)

So, how do you get engineers to play nice?

Plenty of solutions have been suggested; most of them involve Agile in some form or another.

(I personally don’t believe in it. I like—and have used—many of its byproducts, such as Continuous Delivery and Continuous Integration, but I don’t find that the underlying methodology behind the model itself is as universally applicable as it would have you believe.)

About a decade ago, there was a lot of buzz over Spotify having finally, definitively, solved the problem of widescale Agile implementation. It was highly ambitious—virtually utopian in its claimed economies-of-scale, with reports of unprecedented efficiency/productivity gains. Almost too good to be true.

Just one problem: it didn’t actually work. Also, they never actually used it, according to the testimony of one of the senior product managers involved in implementing it. Despite a grand showing in 2012, Scaling Agile @ Spotify was pretty much DOA before it had even hit the ground.

In hindsight, it should have been fairly obvious that things over at Spotify weren’t as brilliantine-sheened as the glowing whitepaper they said contained the key to their company’s success may have suggested. Years of complaints about incomprehensible UX decisions seemingly passed unilaterally with little user (or developer) input; a platform that abruptly pivoted towards delivering podcast and, strangely enough, audiobook content with almost the same priority as music streaming, and a lukewarm reception to the arrival of social networking capabilities.

So, what went wrong?

Firstly: every single organizational unit under this model, with the exception of Guilds, were ordered as essentially fixed, permanent structures. If a Squad was assigned to work on UX, that was their sole responsibility, unless a member had other duties through a Guild (more on that later). Accordingly, each Squad had equal representation within a Tribe, regardless of how important or pressing their work was. Further, each Squad had its own manager, who existed in direct opposition to three other managers in the same Tribe, who all had diametrically opposing interests due to representing different product segments. If an overriding voice was required, Spotify sought to preempt such issues by including a fifth Übermanager in a Tribe, who did not actually have a day-to-day purpose other than mediating disputes between managers, presumably because such instances were or were expected to be extremely common. (It is unknown whether this fifth manager was included in a similarly structured college of Middle Managers).

Worse, yet, however, is it becomes painfully evident how little work could get done under such a model. Because Tribes were, by design, interdependent on each other due to cross-pollination of key devs through Guilds, a work blockage in a Tribe not only required the intervention of two or more Tribes, but required the key drivers of the entire Tribe to do so, preventing any of the involved Tribes from doing any meaningful work. This is on top of the presupposition that each Squad has had to have mastered Agile in small-groups for the idea of an Agile economy-of-scale to even make sense.

Probably most damning, though, is the impulse to just double down on your own work when confronted by a deluge of meetings, progress reports, post mortems, and pulse checks. Rather than focusing on the interconnectedness of the Team-Tribe-Guild structure and how to best contribute as but a small part of a greater whole, many Spotify engineers simply did what they are instinctually led to do and submitted product as if working in small-groups.

This essentially created a “push” rather than “pull” system where engineers would deliver the product they had believed higher-ups would expect them to deliver, rather than the actual direction that Spotify executives wanted to steer them in. When noticed by upper management, these facilitated “course corrections”. Sweeping, unilateral, and uniquely managerial.

And that was pretty much the end of Agile for Spotify.

Things look well enough in miniature, but the problems become more clear the more you scale upwards.

So, why even talk about this?

I’ve had plenty of good collaborative experiences with engineers in industry. I want to work with people—I have worked with people, and well. But I believe there’s a science to it, and as engineers, we simply do not focus enough on the human element of the equation. The Tribal model reminds me a lot of Mocks, and even the POGIL methods we’ve used in this course so far.

Mocks are a way to implement that at an individual, codebase level. POGIL teaches us to think for ourselves and expand our individual skills. I think what Spotify failed to recognize is that people do not instinctively know how to work together, especially tech-minded people like engineers. Interdependence isn’t something to be cultivated absentmindedly, as if we could ignore the effects of losing the one person who knows what piece of the pie to cut for a day, week, or more; rather, it’s something to be warded against.

Some food for thought.

Kevin N.

From the blog CS-443 – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.

Hi, there!

I’m Kevin N., a CS major and a senior at Worcester State. Thanks for taking the time to read my blog. Since I’m taking CS 443 with Professor Perez this semester, I’m creating this blog as part of my course obligations.

Some things about me:

• Favorite film: Jacques Tati’s Playtime (1967)
• Favorite show: M*A*S*H
• Prior “education”: Three years at WPI. Transfer.
• Next on the bucket list: Ski chalet vacation in Vermont (I wish!)
• First industry job: AFCEA fellow-slash-golf caddy. Don’t ask.

Why CS? I heard the pay is good, and I thought I liked math.
Then, one day, Calc IV happened.

Why 443? I need it to graduate!
Alternatively: I heard the professor is good. (Cough.)

What next? I’ll be adding to this blog as required of me. Check back throughout the term for additional blog posts as I receive more prompts.

Nice to meet you, and looking forward to a successful term!

Kevin N.

From the blog CS-443 – Kevin D. Nguyen by Kevin Nguyen and used with permission of the author. All other rights reserved by the author.