X
Contact Us
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
219 Design offers a 2-Day Workshop called Essential Modern Software Infrastructure for leaders looking for help setting up their software team for optimal success. Daniel Gallagher and I put together this handy 4-part guide for people who want to do it themselves or get a sneak peek of what the workshop covers. In part one, we will share a few core principles we live by here at 219 Design that help us deliver great code. Parts two, three, and four will cover practical applications of those principles across areas such as testing and processes. Included throughout are reading recommendations for further discussion on every topic.
Although the mechanics of various pieces of software infrastructure differ, there are unifying principles at work throughout. Moreover, these unifying principles can be readily understood, applied, and debated by software experts and non-experts alike. In this way, they bridge the gap between the software arm of your organization and the remaining non-software business units. In Essential Modern Software Infrastructure, we introduce these principles up front, to provide a context and rationale for the infrastructure pieces proposed later in parts two through four.
Friction in software development is anything that takes precious time or mental energy away from the task at hand – developing a system. Examples of friction could be: long compile times, long test times, manual tests, or transferring files between folders or machines. Removing friction makes the day-to-day both more efficient and more pleasant. It also frees up your mental energy to be put to better use solving interesting problems.
Fighting complexity is a constant battle and it takes sustained diligence to remove friction at every step. That means no premature optimization – do this as you go. This also means no premature pessimization. Don’t get locked in prematurely – remain flexible so you can iterate to reach the best solution. Remember, unlike hardware, software is malleable. The same risk factors do not apply. Finally, never let perfect get in the way of good enough. Getting from 80% to 100% is often not worth the additional cost and tends to lead to premature pessimization.
Like all the principles listed here, we can apply this thinking across the organizational hierarchy. Fighting complexity is mandatory inside your source code repository, but it is also good practice to fight complexity in your methodologies and team structure.
YAGNI – “You aren’t gonna need it” is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.”
Choose Boring Technology – the benefits of choosing tried-and-true technology
Robot QA. Robot DevOps. Robot Code Review.
Automation is your robot personnel army! Spending time now will save you a lot more time in the future. The key is to keep a mindset of always thinking in terms of moving toward the goal of a better automated system.
Manual Work is a Bug – an example of how to move from manual to automated in a few simple steps
Foster virtuous cycles and build momentum by building nested feedback loops. Get feedback from each new line of code, on every feature added, and on new team processes. Nested cycles include examples like developer tests for every line of code, user acceptance tests for features, regular introspection for team processes. If an amazing new process was introduced 3 months ago, and was super helpful for 2 months, but is more of a hindrance than a help today, transform it (or get rid of it)! People and companies learn and change and grow, and need different processes and guardrails at different times. Fast automated tests provide rapid feedback for software engineers. Continuous integration provides automated feedback across a set of supported platforms. Automated releases provide feedback to the whole organization about new feature availability. Dogfooding (where possible) provides feedback from various internal users to the engineers.
To be agile, develop short iterations to yield meaningful feedback, scale back scope to meet time and budget goals, and maintain less mass.
One caveat: when examining feedback from each iteration, double-check that you measure the right things or risk landing in a local maxima.
Manifesto for Agile Software Development – rules for arriving at your concrete habits. Agile doesn’t mean sloppy!
What is Timeboxing? – A timeboxed approach decreases procrastination, as well as perfectionism.
Software Inventory – A metaphor for visualizing the cost of having an inventory of unshipped code.
Build a “no hoarding” culture by keeping the knowledge flowing. Document it and keep the bar low to “publishing” it. Many teams prefer an internal wiki for sharing knowledge. We find that a simple “docs” directory at the root of the repo is also a cheap and effective way of sharing knowledge.
It’s also critical to conduct blameless postmortems. Failure is an asset if you learn from it.
A happy side-effect of writing concise tests: the tests become sample code snippets that teach the rest of the team how to use that module.
A happy side-effect of using Infrastructure-As-Code in your Continuous Integration: you then have iron-clad documentation of your toolchain requirements, which can be useful in many contexts, all the way from FDA documentation to onboarding new engineers.
The Time I Stole $10,000 from Bell Labs or why DevOps encourages us to celebrate outages.
You’ve all heard the sayings, “If it sounds too good to be true…Don’t believe the hype…” There is no substitute for critical thinking. Software engineers like to think of ourselves as hard-nosed scientific thinkers, but the truth is that software has fads and fashions (as do most hard science fields!).
No Silver Bullet – Essence and Accident in Software Engineering – Brooks argues that “there is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity.”
Examine trade-offs and avoid dogma. Don’t let your current thoughts and ideas be derived only from what you used to think. Everything is changing so question everything and don’t be afraid to change your mind. The earth turned out not to be flat after all.
“A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.” Ralph Waldo Emerson
We have argued in favor of common sense principles. In Parts Two though Four of Essential Modern Software Infrastructure, we will share some practical applications related to source control, automation, containers, testing, and more.
Keep Calm and Automate On. And contact us if you get flummoxed along the way!