As a software developer, one of the important and useful activities after a major software project has been completed is the POSTMORTEM.
This is essentially an after action report summary outlining the things that went right and wrong with the implementation of a project.
Their usefulness is pretty much self-explanatory. It stands to reason a developer will continue to duplicate the actions and activities in a postmortem that contributed to the overall success of a project.
Just as importantly, and perhaps even more so, a developer will learn from the mistakes and things that went wrong in the execution of a project. I can only speak for myself, but the best way I learn is by making mistakes.
Software development is actually a lot about learning through mistakes.
When I write software, rarely do I write code perfectly the first time. My compiler constantly complains about syntax errors, runtime errors and logical flaws and defects.
It’s only by figuring out the solutions to those errors that I gain insight about how to make code work the way I want it to.
It’s not just learning by discovering code mistakes. Coding is only a very small portion of software development. There are a whole bunch of other activities, including planning, analyzing and researching, interacting with others, and a slew of other tasks one must master to be successful as a software developer.
Postmortems allow a developer or team of developers to summarize the things that went right and wrong with a project. Learning from postmortems is a great way of avoiding those same mistakes in future projects and applying the things that went right.
And I can’t think of a better postmortem than real-world enterprise-scale software applications that are literally out of this world.
I highly recommend that every software developer read the book “The Martian Principles For Successful Enterprise Systems: 20 Lessons Learned From NASA’s Mars Exploration Rover Mission” by Ronald Mak.
You won’t have to worry about slogging through an epic Leo Tolstoy-esque tome… it’s a very slim book and you’ll probably be able to finish it in one or two sittings, tops.
But it doesn’t diminish how enjoyable and enlightening you’ll find it.
It’s essentially a postmortem writeup of the enterprise application developed at NASA to support the famous data and soil sample gathering missions of the 2004 rovers, “Spirit” and “Opportunity”.
The high-level objective of those rover missions was to use robotic controlled vehicles to dig for soil samples and other data and search for clues of past water activity on Mars.
The mission was a total success and has sent hundreds of thousands of high-resolution color images of the Martian surface, along with countless amounts of geological data in support of the fact that Mars was once a very watery planet.
The author of the book, Ronald Mak, was the lead NASA enterprise architect and software engineer behind the key enterprise application developed to support the Spirit and Opportunity rover missions.
The goal behind the enterprise application, was to allow for 24/7 real-time access to all data gathered by the Mars rovers, so it could be viewed by all key NASA personnel as soon as the data became available.
Easier said than done. Scientists and engineers all around the world naturally wanted access to the raw data uploaded by the two rovers, as soon as they became available, so the enterprise application had to be designed and built with scalability and maximum throughput, from the get-go.
Mak’s book is all about the mistakes and lessons he learned from undertaking such an important and mission-critical application.
Many of us software engineers can be proud of our own successes and achievement, but how many of us can boast that our applications have helped humanity gain insight and knowledge about our universe and the meaning of life?
The book is divided into chapters that are broken down by certain software principles, hence the title. There are 20 principles in all, and Mr. Mak details the real-life lessons he gained as he worked on his enterprise NASA application.
I won’t go through all twenty lessons, but there are some 5 that stood out and resonated with me.
Principle #1: “Don’t reinvent the wheel”
Back in the earliest days of computer programming, programmers pretty much had to write everything from scratch. The first generation computer programmers and hackers didn’t have the advantage we have today of software libraries and frameworks.
Need to sort an array? You’re gonna have to write your own. Need a library to connect to an external database? Yeah, start coding it.
The first generation programmers had no choice but to write everything from scratch… there simply weren’t any existing libraries of code around that they could use. So they had no choice but to bite the bullet and write it themselves.
That was then, but this is now, and a lot of water has passed under the bridge since those earliest days of software development.
Today, the “low hanging fruit” of programming has long since been taken care of. Things like string manipulation, sorting data arrays and other data structures, connecting to and querying databases, and lots of other low-level type programming, have been written by many programmers and architects and bundled up as libraries and frameworks for the benefit of the programming community at large.
Microsoft designed the .NET framework, which bundles up a lot of this low-level functionality into a big set of software libraries. The Java programming language has a similar set of bundled libraries. Pretty much every major programming language on the planet has its own set of libraries.
There’s really no reason for a software developer to rewrite any of these low-level computer routines anymore.
This “boilerplate code” really only needs to be written by someone ONCE, because it never really has to change.
The value-add we developers provide to a project is the specific and unique business functionality the project requires, and reinventing the wheel is an unnecessary waste of time.
Principle #4: “Get something working as soon as possible”
The first milestone of any project is an important, if not the MOST important, task of a project.
The book describes it as an “end to end thread” of functionality. An end to end thread of functionality is implementing just enough functionality of an application to prove the overall architecture and design of the application is sound.
The core idea behind end to end functionality is creating a full “round trip” of functionality.
For example, if a project required the creation of a website that needs to connect through a middle tier of microservices and to a backend database tier where data must get permanently persisted, then your end to end thread of functionality needs to connect through the middle tier of microservices and to the backend database tier.
The thread only has to have the bare minimum level of functionality to prove a client-side HTML page can connect to the middle tier, the back-end tier, and make the round trip back through the middle tier and return to the HTML page.
Why is this so important? It proves the overall architecture can work.
This is an extremely powerful milestone. When you can show and demonstrate to your project manager, product owner, and your business’ customers that you have a working and up and running application, no matter how simple and crude it may be, you give everybody confidence the project has a strong chance of success.
Principle #7: “Plan to make changes”
The principle of assuming your application will undergo changing requirements is probably the most common mistake that trips many developers, including myself, up.
In the book is a little anecdote about how one of the menu systems inside the core enterprise application was hardcoded with the years 2003, 2004, and 2005, to correspond to the three-year mission parameter of the overall Mars rover mission.
Nobody thought anything of it, so nobody cared that those years were simply hardcoded into the application.
That is, until it was deemed necessary to add 2006 and 2007 to the duration of the project. A simple mistake, but one that trips up many developers who assume project requirements will never change.
On the contrary, the one fact you can always count on is that project requirements will inevitably change.
That’s why it’s so crucial for your application to be flexible and resilient to change. It should be designed in a way that it’s actually easy to change things like settings and configuration values.
Prime candidates for dynamic configuration are things like database connection strings, web addresses and user security accounts and logins.
Principle #13: “Log everything”
The principle of logging as much activity as possible is another important principle that we developers often neglect.
We tend to assume the “happy path” of programming. We often work under the assumption that our application will never fail. That the underlying network connections to the external servers and databases will always be there. That the disk space of the servers will never run out of space.
But these things inevitably always do fail, sooner or later. It’s important to log failures when they happen so that we developers and other support staff can get a better idea of fixing the problem.
Without logging, there’s not even a slim chance of figuring out where to start troubleshooting a problem.
Logging gives us the information we need.
Principle #18: “Don’t ignore people issues”
It’s easy to forget that computer programming isn’t just about dealing with computers and machines.
The other important half of the equation is the PEOPLE involved in a project.
The success or failure of a project is ultimately dependent on the people behind the project, not the code, as strange as that may sound.
When you have a team all working well together and working towards the same goal, the chances the project will succeed, are exponentially higher than a toxic team where there is little or no leadership and where all the team members are bickering and fighting amongst another.
Teamwork and communication are extremely critical to the success of a project. Without both of these, a project is usually doomed to failure.
We all make mistakes. Its the only way we learn, really. By making mistakes and learning from our mistakes, we gain clarity about what not to do. It may seem counterintuitive, but making mistakes is how we learn quickly.
The smart person learns from their own mistakes. The WISE person learns from the mistakes of others.
This book is a great shortcut for all developers who want to learn from the mistakes and successes of a project that is literally out of this world.
I’m really trying hard here not to cue up the theme music to Star Trek right now…