A deep discussion on that tension between development speed and software quality. What is velocity? How does it differ from speed? How do we measure it? How do we optimize it?
Brandon Rhodes’s solution to conflicts between his
~/bin scripts and system binaries: the humble comma
I heartily recommend this technique to anyone with their own
~/bin/directory who wants their command names kept clean, tidy, and completely orthogonal to any commands that the future might bring to your system. The approach has worked for me for something like a decade, so you should find it immensely robust. And, finally, it’s just plain fun.
Building products is a difficult and time-consuming effort. Figuring out what the problems, finding a potential solution to that problem, and then building that solution all take a decent chunk of time and effort. It’s due to this process that the minimum viable product was born. The motivation for building an MVP is still valid. Build something small and easy to test, launch quickly, and pivot or trash it if it doesn’t perform as desired.
There is another, less selfish way.
I read an article by Jason Cohen a few years ago which changed the way I think about product development. Instead of building MVPs, we should be building SLCs. Something Simple, Loveable, and Complete.
I like the thinking behind SLCs. So simple, so loveable, so…
Hat tip to Henry Snopek for linking this up in the #gotimefm channel of Gophers Slack! When it comes to thinking about your projects, Henry says:
I like to use MVP for fast projects, and SLC for “effective” projects…
Yeah, I like that framing too. So simple, so loveable, so…
Anyone who’s worked in the tech industry for long enough, especially at larger organizations, has seen it before. A legacy system exists: it’s big, it’s complex, and no one fully understands how it works. Architects are brought in to “fix” the system. They might wheel out a big whiteboard showing a lot of boxes and arrows pointing at other boxes, and inevitably, their solution is… to add more boxes and arrows. Nobody can subtract from the system; everyone just adds.
Nolan posits the center cannot hold and the current market shift from bull to bear might help bring the collapse of complex software. But it’s never that simple, is it?
One thing working in complexity’s favor, though, is that engineers like complexity. Admit it: as much as we complain about other people’s complexity, we love our own. We love sitting around and dreaming up new architectural diagrams that can comfortably sit inside our own heads – it’s only when these diagrams leave our heads, take shape in the real world, and outgrow the size of any one person’s head that the problems begin.
Victor Engmark thinks we should start test names with “should” for a handful of reasons, here’s a few:
- It removes redundancy, because the function name should already be in the call stack.
- It is falsifiable, a person reviewing the test can decide to which degree the name agrees with the actual test.
- It encourages testing one property of the function per test
I don’t disagree, but I like to take it a step further: Let the “should” be implied by the rest of the test name.
should replace children when updating instance
replaces children when updating instances
should apply discount when total cost exceeds 100 dollars
applies discount when total cost exceeds 100 dollars
Most of Victor’s reasons for using “should” still apply with this format, but it’s less verbose and more accurately describes the software working as expected when the tests pass.
Unreproducible issues, although rare, are typical for each project, sooner or later. They can affect different system parts and make us many causes for investigating and fixing them.
In this article, I try to share some of the techniques I have used in such investigations, which gave me great help in such scenarios. I hope they are helpful to you (if you did not use them already). And, if you have techniques of your own, share them!
Flat file web software is about having a set up which doesn’t use a “traditional” database. Instead it uses plain text files, other files, and/or maybe something like a json feed to store the data.
In this post, he explains why he thinks flat file web software is on the come up (again):
Flat file software can be powerful. Depending on what you need. And I think with the right developers and brain power behind the movement it can be more scalable and secure. The sky’s the limit. When I hear a developer saying, no, flat file isn’t good because… really all I’m hearing is they don’t want to change the way web software works. Because what I’ve found is most anything is possible.
Here’s a couple of flat file platforms which are incredible. One is a CMS/blog, the other a forum. Yes, a flat file forum.
A somewhat-related categorical question: Does SQLite count?
Chris Kiehl hits his hammer right on the head of this common sentiment in software circles:
Developers from certain languages [Java] have learned to wield this design principle with more power than many others. It’s how we end up with so much stuff in code bases that’s just… there. Existing. Superficially it appears unused, but silently and stoically, we know it protects us from the turbulent future change which lurks ever ahead.
The antithesis of one of my favorite design principles: YAGNI
Robby has a chat with Jerod Santo, the Managing Editor and Partner of Changelog Media. Jerod helps lead and co-host Changelog’s flagship podcast, The Changelog, and builds all the cool stuff that makes Changelog awesome. Jerod shares his journey from being a typical networking engineer (Infosec) to the experienced programmer that he is today and his programming wisdom from the trenches.
Tune in as he highlights the undeniable importance of automated test suites and code readability, describes the arc of an engineer’s career, and talks about the past experiences that make him lean more towards clarity over cleverness when coding. He also shares some of the things engineers should consider in regard to pulling in third-party code or writing from scratch, and so much more. Enjoy!
Thanks for having me, Robby! 💚
James Simone ponders the relationship between healthy teams and performance in the software world.
Here’s what it comes down to: teams perform well when successes are shared and failures are owned… We don’t celebrate successes enough, and part of that (I think) is caused by the feeling of pressure that comes from working on a project that seems dooomed to fail without meticulous and ever-present attention.
He goes on to delve in to the source(s) of engineering failures, the dangers of “brightsizing”, known predictors for project success, and a bunch of related topics. Lots to ponder here alongside James, who’s seen a lot of software projects live & die during his eight years in the business.
This guide is built on top of some examples from the book
Concurrency in Goand
Go Programming Language
Covering race conditions, mutexes, deadlocks, channels, patterns, and more.
We’re talking with Woody Zuill today about all things Mob Programming. Woody leads Mob Programming workshops, he’s a speaker on agile related topics, and coaches and guides orgs interested in creating an environment where people can do their best work. We talk through it all and we even get some amazing advice from Woody’s dad. We define what Mob Programming is and why it’s so effective. Is it a rigid process or can teams flex to make it work for them? How to introduce mob programming to a team. What kind of groundwork is necessary? And of course, are mob programming’s virtues diminished by remote teams in virtual-only settings?
Basic premise is: browsers are great at navigating pages, let’s leverage that by serving users directly with HTML. This already gives you half-decent pages but you can go further and sprinkle on some sugar. A bit of JS. Instead of reinventing the world in JS let’s try to really use what modern browsers provide natively and then push just a bit forward.
Is the pendulum starting to swing away from SPAs/client-side rendering and back toward MPAs/server-side rendering? Will we ever find balance somewhere in the middle?
In this post, I will talk about important factors you should consider when architecting systems that are powered by third-party systems. The factors I detail are:
- deployment model
- technology coherence
- NFRs and SLAs
- Infrastructure and hardware needs
- API style and documentation
- Idempotent APIs
- Getting data out of the third party provider
Frank Krueger joined us to talk about solving hard problems. Earlier this year he wrote a blog post titled “Practical Guide to Solving Hard Problems,” and a lot of what he had to say really resonated with us. The premise is simple — if you have to write some code that you’re just not sure how to write…what do you do? What are the practical steps that you can take when you’re feeling stumped? Today’s show goes deep on that subject…practical ways to solve hard problems and ship your best work.
Frank has his own podcast called Merge Conflict — check it out at mergeconflict.fm.
With the recent events relating to Google Analytics platform, it’s becoming very clear that the time has come for many of us to migrate from Google Analytics to different platforms.
In this article we will go over both the “Why?”, so that you can make an informed decision whether you need to migrate of not, as well as the “How?” of migrating from Google Analytics - that is, quickly and easily taking your data and moving to different analytics platform without too much hassle.
When hiring developers, there are many things we are looking for, but over the years I have found that raw coding ability is easily the most important quality to look for. I can quickly train a person to have knowledge in some domain, but I’ve never seen raw coding ability come from anything other than personal commitment to extensive and deep practice. Because of this, I have found that some methods work better than others to discover talent.
… instead of writing code, consider instead having the candidate read existing code and talk about what it does and how it works. This offers some powerful advantages:
The advantages in brief:
- Reading probes the most fundamental skills
- Reading code is way more efficient than writing.
- Reading puts candidates at ease compared to writing code.
Click through for the details and how to put this in to practice.
The reason we find ourselves as practitioners (as an industry as a whole) constantly migrating between different platforms, journeys, and digital transformations… We do this because I don’t think we ever understood the fundamentals.
Nils Norman Haukås:
I have been a big fan of the write libraries, not frameworks argument for a while now. Lately, I’ve come to ponder that there might be a fruitful expansion to this argument, that we should start to value principles over patterns, patterns over libraries, and libraries over frameworks.
I don’t disagree!
The challenge with principles & patterns is they are more difficult to formalize (and communicate) than libraries & frameworks because they’re by nature less specific and more meta (lowercase “m” ftw).
In other words, libraries & frameworks are an end product. Principles & patterns are means to an end. It’s easier to ship a product than to ship the means to it.
The latter is the realm of documentation, education, and conversation.
The Squeaky team goes from dev straight to prod (same here), but many people advocate for (and use) staging or other “pre-live” environments instead.
While there are obvious benefits to deploying to different environments, at Squeaky we’ve decided to take a different approach. We only have two environments: our laptops, and production. Once we merge into the main branch, it will be immediately deployed to production.
Perhaps that sounds unusual, but so far it’s outweighed the benefits of pre-live environments, and we believe it’s helping us to ship faster, and lower the number of issues on production. So, I thought I’d write this post to share why we think it works, and why you should consider it too.
Fine-grained authorization in microservices is hard. Definitely not impossible, but hard. You would expect that a more standardized, all-around, full-proof solution is out there, but I am afraid there isn’t. It’s a complex matter and depending on what you are building, implementation varies.
You will probably start with a boolean
admin flag in your
User model and then you will replace it with a
role field, as we all did. However, as things progress and the business model becomes more and more complex, so do the solutions that we need to implement in order to deal with that complexity.
But how do you actually go from a simple flag to Role Based Access Control (RBAC) and then to Attribute Based Access Control (ABAC), especially in a microservices environment? In the following post I hope to help you get there.
Lars Wikman reacts to Gerhard’s excellent conversation with Kelsey Hightower on Ship It!
So he essentially said, I’m interpreting here, that when it comes to deploying software to servers the documented manual steps for deploying something need to be the canonical reference. Then whether you build bash scripts, Ansible playbooks, Makefiles, Dockerfiles, Terraform, Kubernetes or something else to encode that procedure into something repeatable and scalable that’s a separate step. Having documented the process required to set it up means that there is an answer to the question: How do I get this running? An answer that doesn’t require you to parse the .yml files or grok Ansible roles and groups.
Lars springs forward from there with many thoughts of his own on the matter.
It’s not hard to find articles or pieces of research claiming that the sooner you find a bug, the cheaper it is to fix. But I’ve found there isn’t actually a whole lot of information out there on exactly how to prevent bugs in the early stages of a software development project. i.e. before code is written, while requirements/user stories are being written or just after the requirements/user stories have been written.
Here I would like to share exactly how I help prevent bugs on projects and how I help others come up with ideas on how to prevent bugs as well.