BROADCASTS.com

Published: April 2, 2018, 9 a.m.

This episode is for anyone who wants to effectively orchestrate a development process without becoming the butt of their team\u2019s water-cooler jokes. It's more attainable than you think, because it's all about process. Don't be a Bill Lumbergh - be awesome.

Written and read by Jonathan Sol\xf3rzano-Hamilton: https://twitter.com/jhsolor

Original article:\xa0https://fcc.im/2GW6xFX

Learn to code for free at:\xa0https://www.freecodecamp.org

Intro music by Vangough:\xa0https://fcc.im/2APOG02

Transcript:

Laurence Peter formulated the principle that \u201cmanagers rise to the level of their incompetence\u201d in 1969. In particular, non-technical leaders have earned a poor reputation with software developers.

Office Space depicts the non-technical manager in Bill Lumbergh, pictured above. Dilbert provides the classic \u201cPointy-Haired Boss.\u201d

This article is for anyone who wants to effectively orchestrate a development process without becoming the butt of your team\u2019s water-cooler jokes. I\u2019ll share what I\u2019ve learned over the years managing development and release processes as a manager and software architect at UCLA and Stanford University.

The biggest lesson I\u2019ve learned is that the key to sustaining successful software releases is completely non-technical.

It\u2019s about process.

Some aspects of a development process benefit from technical know-how, but it\u2019s not required. Successfully releasing software into production is much more a question of robust process architecture than design or code alone.

For the purpose of this article, we\u2019ll assume you\u2019ve already agreed to start building something. The product approval pipeline is a different process. Today we\u2019re focusing on getting the agreed-upon product from concept to production.

What to build

Your team needs to assemble a clear roadmap for their code. Architects and manufacturers use blueprints. You should too.

Your roadmap should include a set of schematics which each fulfill a different purpose. These schematics differ for individual applications. A user-interface mock-up, application architecture diagram, and business process model are common. More detailed component diagrams such as Unified Modeling Language (UML) diagrams and flow models are often useful as well.

Technical expertise lets you use these schematics to critique your team\u2019s architecture and ensure they\u2019re on the right track. Even without technical skill, these schematics will be critical.

You can use them to drive productive conversations about product completion. No more will you have to draw a \u201c% complete\u201d out of thin air or best-guess from the development team. You can track the status of each item on the diagram to determine how close the app is to completion. You can also project future velocity based on how quickly the team completed prior components.

There is no \u201cright\u201d amount of pre-development documentation, but there is one wrong amount: none. Work out with your team what constitutes an acceptable roadmap before they start coding. The first checkpoint in your development process will be to review this documentation and ensure they\u2019ve met this agreement.

What not to build

Your team can\u2019t build everything. Nor should they. You need to ensure that your developers have a laser focus on what they actually need to build.

Why are you building this app in the first place? Define the key differentiation from existing products. 80% of your team\u2019s time should go toward supporting that differentiation.

The schematics you should now have will be helpful here. Does your application include a logging component? A sign-up and login process? There are already excellent free, open-source software (FOSS) frameworks in most languages for these components. Some are available under extremely permissive licenses.

Tesla provides a great illustration of this concept. Their first key differentiator was to use a lithium-ion battery to make electric cars competitive with gas. Lithium-ion achieved this by reducing battery weight and increasing range.

The first Tesla prototype simply converted a pre-existing electric sports car from lead-acid to lithium batteries. Their first production run was mostly a Lotus Elise roadster (a pre-existing sports car) that had a Tesla battery and motor.

The lesson for your team is to use what already exists wherever possible. If you can use or adapt a FOSS package, do it. Even if you need to license for-pay code from somewhere else, it\u2019s almost always worth it.

Get all the scaffolding in place quickly so you can test your \u201clithium-ion battery.\u201d Then you can iterate through and replace whatever will help further differentiate your product without stressing about delaying production-readiness.

The second checkpoint of your development process is to review the planned architecture with your team and identify what very limited part they intend to build from scratch.

If it sounds like something that already exists, and it\u2019s not the core focus of your product, challenge your team to see why they believe they need to re-do it.

Don\u2019t just throw it over the wall

Once you have identified what pre-built technologies you\u2019ll use, make sure to review these with your production support group.

Database and server administrators will need to plan for installing and supporting any new technologies. This is the third checkpoint in your development process: operations readiness.

Keeping the production support team in the loop early is 90% of the secret sauce known as \u201cDevOps.\u201d If you haven\u2019t heard of this, DevOps is the idea that software development and production operations teams should unify under common goals.

The proposed benefits include much quicker releases, more reliable code, and more time spent developing due to automation. These are all great boons, but they follow from a strong communication process. Automation follows, not replaces, collaboration.

Implementation and Testing

Now your team writes the code. Collaborate with your implementation team to devise a process for dividing the work among themselves. There\u2019s no one-size-fits-all approach, and this is where the \u201csoft skills\u201d of leadership dramatically outweigh any technical skill.

Some developers will want to hog all the \u201cinteresting\u201d work and ignore any drudge work. They may believe that they\u2019re the smartest person in the room and should get their pick of assignments. Others may resist change and only want to do the same kind of work they\u2019ve done before.

Lead your team into an equitable distribution of work. Challenge everyone to grow appropriately and to share and collaborate.

One more technical aspect of the implementation is that the code must include sufficient automated tests. These are code-defined tests that a test system can execute.

If the code\u2019s going to crash, don\u2019t you want these guys\u2019 resumes to be on the line instead of your own? (public domain: US Government photo)
Manual \u201ctest scripts\u201d where a human interacts with the code to see if it works are insufficient and reflect technical debt. Your technical team should at least include unit tests. Test-driven development is a popular approach for ensuring that critical code is always tested.

You can drive a non-technical conversation with your team about their \u201ctest coverage\u201d (the portion of the code that is tested). It\u2019s pretty simple: ask them to list their assumptions. Then ask where and how they test these assumptions.

The checkpoint at which the code is believed complete by the developers is referred to in my shop as dev-complete. It means the primary development (dev) process is over, but additional code may be written to address issues that come up in the review process.

In an agile development process, you will typically divide the implementation process into multiple checkpoints instead of one all-or-nothing deadline. These are typically called iterations.

Refer to the roadmap you defined in the first step. Before starting new component(s), ensure that what you\u2019ve already started is at least dev-complete. This provides you with an accurate view of the speed of development and reduces risk.

As you complete the iterations, you can push the code to an environment for \u201cacceptance testing.\u201d This involves pilot or test users (or an internal team playing that role) who interact with the partial product. They test to ensure it meets the design expectations and provide feedback on how it could be better.

Acceptance testing is not a substitute for the unit testing mentioned earlier. It serves a different purpose. Letting your development team lean on acceptance testing to catch basic functional bugs is a recipe for disaster.

Feedback from the acceptance testers can be incorporated into the next iteration. This is another good reason not to bite off a big chunk of the product all at once. You want to leave room to change course once people start playing with the product.

Once you\u2019ve accumulated enough tested code to constitute a sufficient product release, you\u2019re ready to begin the release management process.

Looking for bugs in all the right places

Your developer or team has reached a point where they believe the code is done. Acceptance testers are satisfied with the way the product is working. The next checkpoint in the process is to validate the belief that you have code ready to become a product. Let\u2019s start reviewing the code!

You may not be comfortable or have sufficient technical know-how to review the team\u2019s code yourself. That\u2019s ok! You don\u2019t have to. Your process has to.

Work with your team to identify a process for code review that works for them. If you have more than one developer, peer code review works great. If you don\u2019t, are there other developers in your organization outside of your team? Work across team boundaries to establish a peer code review program.

If there really is only one developer, then sit down with them and have them walk you through the code. Use your schematics as a reference point, and ask them to tell you how the code accomplishes the schematic\u2019s goals.

At the conclusion of the code review process, the developer and reviewer(s) should feel comfortable with being held accountable for the code.

The code review is also a good time for reviewing two other critical points: documentation and security.

I\u2019ve already written about a sustainable documentation architecture\u200a\u2014\u200acheck it out if you\u2019re interested!

Security review should be a part of any code review. In general, this involves taking a second look at the code to spot weaknesses where an attacker could exploit it to reveal private data or gain control of the server. It must be done by a technical person.

The Open Web Application Security Project (OWASP) publishes a free comprehensive guide to security review.

Your developer can do this if they\u2019re the only one on the team, even if they just run an automated security code analysis tool. There are free tools for helping with this process which are linked through the OWASP wiki.

Eject, eject, eject!

The code has passed the review process. It\u2019s ready to become a product. But that doesn\u2019t mean it\u2019s ready for production.

The last checkpoint to clear is deployment readiness. Is your code in a state where it\u2019s easy to deploy to production? This should involve as few manual steps as possible.

It also means you need to have a plan for reverting the change in case the code doesn\u2019t work as planned. This is called a \u201crollback plan.\u201d

If you have a separate software operations team, this is where they come back into the picture. They should review the deployment and rollback documentation and let you know if it\u2019s sufficient.

If you don\u2019t have these personnel you can perform this step yourself. Make sure that there are clear, simple instructions for deploying the product. There should be very few manual steps, as each manual step introduces a chance for human error.

There should be a clear, sufficient plan for returning to the prior state of affairs if the deployment doesn\u2019t succeed. This may be as simple as restoring a backup, or it may involve customer communication or data conversion.

Whether the plan is sufficient depends on how thoroughly your team tested the code, and how widely the product is being released. Consider also any risks associated with the product or with this particular release.

Once you\u2019ve passed this checkpoint, push that code into production!

Post-release

Succeed or fail, it\u2019s important to circle back and review how the process went.

Did your team accurately estimate the effort required to release a product? Did the testing adequately model the production scenario? Revisit the implementation and testing checkpoints, and review how well the team performed.

How is the product running in production? It\u2019s a good idea to visit the operations staff and obtain their feedback. This further creates trust between the development and operations teams, and will lead to more DevOps benefits down the road.

Where are the remaining gaps in your product? If they\u2019re in third-party code, now\u2019s the time to consider whether to customize your packages or re-implement from scratch. Otherwise, you now have input on what to build for the next release.

Above all, hold yourself and your team accountable for the results of your effort.

Accountability facilitates independence and promotes individual growth. As your team grows accustomed to being held accountable for each step in this process, they\u2019ll adjust their performance accordingly.

Conclusion

You don\u2019t have to be the least bit technical to run a successful software release process. Technical skill can help, but it can also become a crutch.

The key to successful software release is a well-documented, well-understood process for moving software through the pipeline from idea to product. You now have a starting point for drafting your own software release process.

What\u2019s most important is that you participate with your team in filling in the blanks and creating a repeatable process that works for all of you.

It doesn\u2019t have to be perfect for anyone, but it does have to be understood by everyone.

You also need to ensure that the velocity of your product through these checkpoints matches the demand for the product. None of these items need to be multi-day show-stoppers. It could be a simple one-page checklist. You need to define a process that fits your environment.

As with any process, you should also iterate. Just like with the code, your first, untested draft isn\u2019t likely to be perfect. Tune the process on each run-through and you\u2019ll end up with a smooth, predictable software release path.

And remember to brush your hair. You don\u2019t want it looking\u2026pointy.