Andy Hunt's Blog

So much is written about projects and software assuming a fresh start, a smooth ���greenfield��� project.

Friends, the field has always been brown.

Sometimes black. Usually chunky. Filled with the wreckage of previous projects, orphaned code and aimless practices that shouldn���t even be there in the first place. Ya know; a mess.

One of the things that we always forget is that software development is a completely human endeavor. The programming languages, the container orchestration, the tech stack���all that is secondary. It���s all about us, as people. And people have both history and future.

A ���project��� does not stand alone, isolated. It���s not a mythical, unspoiled green field just waiting for your imprimatur. A project is an integral piece woven into the overall sociotechnological fabric.

That means a project isn���t just a ���thing��� by itself: every project has a before, and every project has an after. Every person on the project also has had a before the project and an after the project.

So not only are we building on the ruins of a previous civilization, but each one of us is bringing our own baggage to the party as well. That ���agile practice��� that was shoved down our throat at a previous dysfunctional project? Yeah never want to do that again. That awesome ���agile practice��� that was so successful on the last project when it was just a few of us? Surely we can scale that to this new larger team.

Both views are wrong���it���s all baggage. The only thing you can safely say from a previous project is that a particular approach or tech worked well or didn���t work well on that project. Maybe this project will have a similar experience, or maybe it won���t. You can���t know yet.

This project is different from any other you or anyone else has every worked on. Maybe only slightly so, maybe massively. But always different. Even if you have the same team members, even if it���s a similar task from a previous project, you are different now. You���re older, more experienced. You learned something from previous projects, for better or worse.

One of the key takeaways from the agile movement is the idea of responding quickly to changes, to the point where you can embrace change, not just grit your teeth and get through it. Let���s face it, everything changes all the time. The tech stack shifts under our feet. Market, consumer, and regulatory forces may drive feature changes and huge pivots to your product. Change is omnipresent, and we have to deal with it promptly and effectively in order to succeed.

So here you are, on a new ���greenfield��� project that ain���t so green after all. How much chunky brownfield have you inherited? Do you really need Kubernates and containers? Would a static site generator and Nginx be enough? Do you really need Redis, Mongo or Couch and a relational DB as well? You could just use Postgres for all of that.

Those stand-up meetings that last several acrimonious hours���does it make sense to continue to do those badly in this environment? What about pull requests, which are great for a large, distributed development team, but which make no sense at all for a stable development team?

How many of the practices you���re team is doing are designed to slow down the work, to introduce chokepoints or single points of failure? Any sort of handoff or gate is highly suspect and maybe, just maybe, not needed at all.

We���re coming into this new project a mess. We���re a mess. The project is already a mess (bonus points if you have over a thousand Jira tickets logged to this project before it even starts). Our teammates are a mess. Our users are a mess. Our sponsors, corporate leadership��� we���re lucky if they are only a mess, and not actively subverting our development efforts, preventing us from learning or growing or even being effective.

So what can be done? We don���t get the chance to start with a clean slate, but we can make some changes. Successful modern software development requires at least four things:

Impeccable, reliable, automated build and deployment system Effective, low-friction collaboration Constant learning and skills improvement Focus on designing replaceable, disposable software

You can read about these four in detail in this article, but the key is to get started making improvements in each area, in the order presented.

That is, the first order of business is to get your automated build fast, reliable, and rock solid. No excuses. If your architecture makes that difficult or impossible, change out your architecture.

Next up, improve collaboration on the team and between the team and users, other parts of the organization, etc. If you have team members that are making this difficult, change out those team members.

Software development is, at its core, all about learning and communication.. You need to schedule time, right along with backlog items and other tasks, to learn and grow your skills. If you don���t schedule it, you won���t do it. So you need to change your schedule to add these activities. This is your opportunity to examine the baggage you���ve carried into this project and update it as needed.

Finally, stop trying to predict the future. As a species, we suck at fortune telling. Yet that doesn���t stop up us from trying to predict a project due months or years in the future, or trying to predict what users will want or need, or trying to predict how software might change in the future. Bottom line, we just don���t know. So rather than trying to build software that will adapt to a situation you know nothing about, aim for the worst case and most likely scenario where the software will simply be replaced. Disposable. Serves the conditions we know about today, and if things change radically, we can just swap it out.

Notice that if you are having trouble with any one of these points, the solution requires you to change something. And therein lies our problem:

If you want change, you have to change.

/\ndy

After the Second Civil War, Henry buys a long-abandoned, desolate mansion from the pre-Internet era to get away from it all: away from the mass surveillance and constant monitoring of the new paranoid state at the very edge of civilization. But there���s more to the house���s history than the real estate listing admitted. Were ghosts real? Or panda bears? Or whales? No one knew for sure anymore. The tapestry of history was torn and threadbare, patched with both tattered cloth and with trash. And in that dim and murky place between the shores of consciousness and nightmare, Henry was running out of time.

For more information, free sample, and floor plans from the books, visit WeatherlyHall.com.

Now available from Amazon.com

/\ndy

Written as a series of self-contained sections and filled with classic and fresh anecdotes, thoughtful examples, and interesting analogies, The Pragmatic Programmer illustrates the best approaches and major pitfalls of many different aspects of software development. Whether you���re a new coder, an experienced programmer, or a manager responsible for software projects, use these lessons daily, and you���ll quickly see improvements in personal productivity, accuracy, and job satisfaction. You���ll learn skills and develop habits and attitudes that form the foundation for long-term success in your career.

Now available from pragprog.com/titles/tpp20

/\ndy

I���ve finished the 2019 #rpmchallenge: ���One album���s worth of music in one month.���
Come have a listen at andyhunt.bandcamp.com. It���s a series of instrumental progressive rock jams, with splashes of ambient textures, jazz and blues. Good music to code to. Enjoy!

far flung thoughts by /\ndy Hunt

/\ndy

In no particular order, here are the four essential parts of a successful, modern software development strategy.

Impeccable, reliable, automated build and deployment system
Effective, low-friction collaboration
Constant learning and skills improvement
Design of replaceable, disposable software

Let���s take a look at each of these.

Impeccable, reliable, automated build and deployment system

You, your team, and ultimately your organization have to depend and rely on continuous, automated builds and deploys.

No matter how skilled you are at working with your users, inventing awesome new interfaces, coming up with great ideas, elegant designs and architecture and more���if you can���t reliably build and deploy the software you���re writing, you might as well not bother writing it at all.

���Civilization advances by extending the number of important operations which we can perform without thinking of them.������Alfred North Whitehead

With the promotion of ���DevOps��� and better tooling, most teams will claim they have such concerns well in hand: version control, build, test and deploy. But are you really capable of continuous builds? Have a look at the assessment section of these related practices:

Version Control
Continuous Integration
Tracer Bullet Development
Automate Everything

Details matter, which is why we���ve started trying to come up with concrete assessments for these basic activities. You might think your team is ready for continuous development, but maybe there are some practices you���re doing that are holding you back. For instance, if you have long-running feature branches that have to be re-integrated to Master at some point in the future, then congratulations! You���ve just re-invented ���waterfall.��� You might want to look to using feature switches in production instead.

Effective, Low-friction Collaboration

���We have met the enemy and he is us.������Pogo

���Us���, in this case, is everyone involved in the project: teams, executives, users. We all have to figure out a way to work together, and that can be hard as all of us have different agendas, different requirements, different skill sets, different values, and different viewpoints.

Regardless of the details of any disagreement on technology, schedule, staffing, etc., the first question to ask is some variation of, ���what���s the point?���

In other words, what is the ultimate corporate vision we are trying to serve? Do we even know? If not, how can we possibly make correct decisions when facing the barrage of low-level, every day issues? One aspect of ���effective collaboration��� is that everyone���from executives to developers���needs to know what���s the point?. You can���t possibly hope to get the organization pointed in the same direction until everyone knows what that direction is, and why we���re headed that way.

Another critical aspect to collaboration is an idea commonly known as ���psychological safety.��� That means you have an environment where it���s safe for people to take personal risks: safe to express ideas and opinions; safe to experiment with alternative designs, different approaches. If team members are afraid of being ridiculed, or of losing status or even losing their positions, then your environment is not safe and you will not achieve any meaningful level of collaboration.

Do you have a sufficient level of psychological safety in your organization? Have a look at the assessments in these related practices and see:

Create Psychological Safety
Small Stable Teams
Team Wide Interruption Protocols


Constant Learning and Skills Improvement

The only defense against constant change is constant learning.

Constant learning is a fundamental requirement of life in any technological field.
But there���s more to ���learning��� than just cramming the API to the latest JavaScript framework.

You have to ���unlearn��� almost as much as you learn.

This is one of the things that throws people who are trying to learn a new development methodology, or learn a new programming language paradigm (e.g., from procedural to object oriented to functional). You have to get rid of the old habits, the old mental maps, the old problems solving approaches, because all of those things are different now.

And yes, it���s constant. Never ending. It���s not restricted to just new and emerging technologies, either. Change comes from everywhere:

Audience and markets
The evolving system under construction
Users��� growing realization of their needs and requirements as they learn them
Technology details (this framework vs. that)
Paradigms (SQL vs NoSQL, OO vs FP, MVC and variants)
Increases in your own skills and abilities

Any modern ���methodology��� should include learning practices for teams as well as individuals. It���s not something you can ignore or relegate to corporate once-a-year ���sheep dip��� training. Here���s a sampling of learning-oriented practices you should be doing:

Three Track Attack
Lunch And Learn
Personal Learning Habits
Learning Journal


Design Replaceable Software

You need to be able to easily try things out. One of the great fallacies of software development is the idea that you can somehow ���figure things out��� ahead of time, devoid of context, devoid of experience. It generally doesn���t work that way; instead, the most effective way to get answers is to experiment: to try it, for real, in the current context, to get real feedback.

No experiment fails unless it gives no feedback at all���in that case you have no idea whether it worked or not. Many experiments will generate negative feedback: it didn���t work as expected. That���s great to find out in the development environment instead of in production, but it means changes will have to be made.

A lot of effort, study, and ink has been spilled on just how to keep software soft and able to be changed easily over time. But as experience has shown us, almost all time spent on designing software to be ���maintainable��� or ���extensible��� is a waste.

Don���t make software ���maintainable��� or ���extensible���; make it replaceable

Instead of wasting time trying to predict a future that will never happen, design software parts to be easily replaceable.

Functional Programming (FP) languages and approaches can help with this idea.

Object-Oriented Programming (OOP) sounded like a great idea at the time, and perhaps implemented purely it might have been, but as commonly adopted we did a very bad thing. Mutable state, temporally coupled and diffused throughout the system, in a tangled, spaghetti bowl of mud���with object-oriented meatballs. Despite all our best intentions, these systems often become brittle fast. In many OO programs, each object is sitting out there like a vengeful ex-spouse, with a long memory and a hidden grudge against the system, ready to pounce and wreak havoc when you least expect it.

Instead of a tangled, intricately coupled OO design, think of a system instead as a series of transforms on data, like a pipeline. Each step���each function���is stateless, with no hidden timebombs or surprises.

With a series of transforms it becomes much easier to test and reason about what the software is doing, and more importantly, what���s up when something goes wrong. It���s much easier to pinpoint the location of the problem and solve it. But it���s not just about testing, it���s about replaceability: it���s about disposable software.

When a component���a step of a pipeline, a function���is suddenly and unexpected made out of date, it should be easy to rip out and replace with something else. The pipeline approach lets you do that easily.

Andy���s Law of Design: If you can���t rip every piece out easily, then the design sucks.

Tracer Bullet Development, which we���ve suggested ever since The Pragmatic Programmer, works nicely with this idea. Make your initial tracer a pipeline: stateless, immutable. Graduate from there to immutable infrastructure. Now you can replace anything that needs replacing easily, and confidently, backed up by tests, with no time bombs or surprises.

For more on Tracer Bullet Development and related practices, see:

Tracer Bullet Development
Small Bites Always
Throw Out Before Add


Do it Now

While these practices are easy to understand, they can be difficult to master. If you���re just starting out with new approaches, please take a look at our suggestions in Starting with GROWS.

For more information on these and other practices, head on over to growsmethod.com and sign up for our newsletter. Don���t worry, we won���t spam you: we���ll only send a few emails a month, and will never sell or rent your email address to any third party without your permission.

If you really want to jump start your change efforts, we offer a two-day workshop as well.

But no matter how you proceed, the important thing is to proceed. If you aren���t addressing these four key areas somehow, your team and your organization will not succeed in this rapidly changing world.

And we���d really like to see you succeed.

Thanks,

/\ndy

One of the largest factors that contributes to success in an organization is psychological safety (cite Accelerate). It���s also perhaps the hardest thing to get right. Countless management articles will tell you that you need psychological safety, but come up a little bit light on the particulars.

Most agree, however, that you have to have an culture and a working environment where:

You feel free to express your ideas and opinions, without fear of being mocked or ridiculed
You trust your team members and your boss to have your back
It���s okay to disagree on approaches, and have a productive discussion

Unfortunately that culture is very much at odds with the classic, stereotypical ���chief programmer��� concept, and with basic human nature. Our species has a particular problem with ego management. Too often, our egos get in our way. Let���s face it, in this industry, we���re all smart people. Maybe top of our classes. Quick to figure stuff out, great at puzzles or brain teasers, word play or trivia (e.g., what���s the shortest legal C program that will compile, but dump core? I can do it in five characters). We want, maybe even need, to show off a little. But that���s just your ego talking.

Consider this analogy: your team (or your whole company or organization) is piled into a leaky rowboat, currently filled with water, adrift in the middle of the ocean. Everyone���s job is to bail water.

No one cares how big your bucket is

No one cares how big your bucket is. The point is to bail out the boat. If the rest of your team has small buckets���or are cupping their hands and trying their best���help them find bigger buckets. It���s in your best interest to help them. The point isn���t to impress anyone with your own bucket prowess. And if, perchance, you are really good with the bucket, share your technique with everyone else. You want everyone to be able to bail as well as you.

Because if they don���t, you���re all going to sink. Even if you���re the best bailer in the world, that���s not enough to keep your end of the boat afloat.

For everyone on your team, you can either learn something from them, or you can teach something to them. Many times, you may experience both from the same person. Our field has gotten so large and diffuse that no one knows it all anymore; it���s just not possible. Odds are, you are not the smartest person in the room. And if you are, then you���re definitely in the wrong room.

/\ndy

The eagerly-anticipated sequel to Conglommora is out! Conglommora Found is now in print and shipping.

Paperback and Kindle editions are available on Amazon:

Conglommora Found (Paperback)
Conglommora Found (Kindle)

And ICYMI, the original novel is here:

Conglommora (Hardcover)
Conglommora (Paperback)
Conglommora (Kindle)

Enjoy!

/\ndy

Paperback and hardcover editions are now available on Amazon:

Hardcover link
Paperback link
Kindle Edition

And you can buy the non-DRM epub and mobi directly:

Epub and mobi

Enjoy!

/\ndy