Dev Profile: Maintenance Master

Introduction

If you’ve ever worked in a service industry, you’ll have noticed that there are many people that just do their job. They go to work, do what they are supposed to, collect their paycheck, and punch out at the end of the day. They fill a role, and they do well at it. They stay out of the spotlight – their ‘off’ time being their fulfilment, and the job being an ends to a means. The same holds true in the Software Development environment.

Software stacks are large these days. Well, at some startups the code base is still growing, but even their, the open source code being referenced is quite large. Now, it’s great when a developer / architect can build and design these larger complicated systems. But as time goes on – new things don’t need to be built out so much as in the past. Sure, things like GDPR can wreak havoc on websites, but for the most part, code bases are pretty stable.

Ideal Scenario

An example of where a Maintenance Master is most suitable: Imagine a stable codebase which doesn’t need to be completely re-written. It needs to be maintained. Minor to Major bugfixes, improvements, business logic changes – these are common maintenance items. This type of work can be well planned out, well tested, and scheduled. Which makes it the ideal scenario for Maintenance Masters.

Advantages

Being able to keep a code base alive and relevant is no small task. Knowing the reason for business logic implementations. Having a history of decisions. Doing all this without checking the Repository history or checking the resolved tickets list is a huge asset. In addition to this, they are great at sticking on a problem until it is eventually resolved. They’ll guard their area of expertise and are predictable about the deadlines they can meet. Sometimes they’ll explore new ideas or concepts – but they are largely happy with the status quo. They are able to churn out a lot of code – but it’s going to be the same code style repeated in every scenario.

To summarize:

  • Consistent
  • Dependable
  • Thorough
  • Content
  • Knowledge Stores
  • Persistent
  • Produce a lot of code

Disadvantages

Being able to stay on a single project or code area for a long amount of time might be great – but it is countered by being unable to see larger solutions or newer approaches that can clean up the code. For example – the DevOps movement has put a huge dent in the abilities of maintainers. Now, their entire process must be revamped. This in turn causes maintainers to become disenchanted with their code or their company – and often will result in their departure for a more stable opportunity.

Not being a part of the huge ‘go getter’ mindset, maintainers don’t typically go way above and beyond the job description. They aren’t typically looking for a promotion and often watch others pass them by. They’ll sometimes get stuck maintaining a failed piece of code without realizing a refactor would be more useful in the long run.

They also sometime lack in their communication skills. They know their job – they expect you know yours, and they don’t anticipate communicating what they are doing outside of what the process makes them communicate.

Managing a Maintainer

There are some obvious do’s and don’t’s when managing or leading a maintainer.

Do’s

  1. Keep their work planned and organized
  2. Give them an area to own
  3. Give them some autonomy
  4. Keep their environment stable
  5. Provide early notice for large changes conceived for their area
  6. Use them to train new people

Don’t’s

  1. Haptic switching of their projects
  2. Expect new ideas
  3. Promote them to architect positions
  4. Use them to interview
  5. Push them outside of their comfort zone.

Summary

Maintenance Masters are an excellent piece of a development team. They will keep the lights on and things stable. They won’t push much of a changing agenda – but they will get things done. If you blame a code base, you’ll find their name dispersed through a file – not as an originator, but as an editor. There is absolutely nothing wrong with being a maintainer – however – if you are one, and you want to move into management or leadership, you’ll need to step out of your comfort zone.

Top 5 Automated Testing mistakes: A tale of Dev Confidence

Confidence Scenarios

Scenario 1: Lacking Automated Testing leads to developer uncertainty

Software Developer Anna is new. It’s her second week and she’s finally gotten everything up an running. HR is no longer making her jump through all of the hoops. Her dev environment is all setup – she’s completed an initial change to the code base – and her first, somewhat, solo change is complete. She sends the Pull Request off for code review – but suddenly notices – she’s gotten an alert about some test failure. Her intro dev comes over to her, and after a quick discussion – she is told how to run the test locally so she can fix everything. Her mentor is encouraging – complimenting her on her quick work to that point. An excellent example of Automated Testing gone right. But not all of us are so lucky.

Meet Dan, he’s pretty much in the same boat as Anna. However, his unwittingly broken code made it through the test suite, if you could call it that. It’s also made it through code review and has just been deployed. Unbeknownst to him, as he sits there feeling accomplished – the website he now develops has just gone down. About 15 minutes pass when he starts to notice a bunch of chatter at the Architect’s desk. Curios, he investigates. As he walks over – the architect exclaims, “Got it, it’s Dan’s check-in!” Dan continues to observe as the architect backs out his change. Anxiety continues to rise as he realizes just how much of the website is down. After pensively refreshing the browser on his phone for what seemed the thousands time, Dan sees a bunch of high fives as the Architect exclaims, “Alright, it should be all up! Dan – let’s go talk about this change of yours.”

Sufficient automated test coverage is key to building developer confidence.

Sadly, the second scenario is all too common.  Instead of spreading confidence around – the development environment awards a lot of it to emergency response heroes. As for everyone else, the only confidence they have – is that their changes are going to break something until they too can become an emergency response hero. Sufficient automated test coverage is key to building developer confidence.

Scenario 2: Contentious Test environment

“Mike and Charles getting into it again?” John asks Elaine.
“Ya, something about testing private methods with reflection”, Elaine replies, quickly adding, “This is why I don’t like writing Unit Tests here.”
“Oh?”
“Every time I try to write one, I get hit up in a code review that I’m doing it wrong.”, she quipped, “The senior devs can’t make up their minds. I know how to write tests for my code – but it’s not how they feel it should be”.
“I’ll keep that in mind – I’m going to talk to our manager about this.” John says as he starts to walk away.

Writing test code is not the same as writing production code. Yet, for those who write unit tests – it’s the same developer mindset between the two. Often developers are highly opinionated and unwillingly to move their opinions. But unit testing doesn’t have to be that hard. A well communicated standard around unit tests is required. But, it needs to be less restrictive then regular code. Causing devs to doubt the addition of a unit test leads to scenario 1. Build confidence by checking that devs are testing the code they wrote – but don’t care so much how they did it. The biggest exception to this is if testing performance suffers.

Scenario 3: Code reuse is not a friend

It’s the end of the day and Ed is adding some new functionality. He’s finished his code work – tested it locally quite thoroughly, and even built an automated test for it. He commits his code and waits for feedback. It doesn’t take long – 30% of the tests fail, but his passed before that happened. Ed start feeling quite discouraged. He did everything right, but now he has to spend the next half day working through the test failures. After this amount of time elapses, Ed realized his override of the base class persisted on a static variable. He cleans up his change and everything passes. Had his test been entirely encapsulated – a lot of the discouraging troubleshooting would have been avoided.

A great developer knows when Worse is Better

A good developer is familiar with DRY and Code Reuse. A great developer knows when Worse is Better. For PHPUnit testing, I’ve seen many practices of creating helper methods – and extension abstraction to create a ‘base’ test class. In all of these instances – the piece built to help cause frail tests. Doing things the right way for development is not the same as doing things the right way for testing. Some examples of ood reuse are mock objects. Some examples of bad code reuse are helper methods that perform actions – and – class extensions of PHPUnit or CodeCeption classes.

Scenario 4: Missing the point

Alex is looking through George’s code review. The functionality of the code looks great – there are even some well built unit tests – they cover every method. Alex can see that the test harness already ran and passed and goes on to approve the code review. Time passes. Jenny is modifying the code that George wrote. She doesn’t know much about the code, but she’s used to trusting the Automated Test suites to keep her safe. She makes some changes, checks them and after they pass and make it through code review – she remarks to herself how glad she is the Tests are in place. Once again, a website goes down and her confidence is shaken. What Alex and George failed to notice, is that even though all methods were built out as ‘tests’, and there was 100% code coverage, the tests were only checking that a return occurred. They didn’t care so much about the content.

This is a simplified scenario, but it is quite frequent. Often, devs will focus on the quantity of the test, instead of quality. Or they will conflate quality with ‘live’ code standards as in Scenario 2. A false sense of security from poorly built tests that always pass is missing the point. The point is to fail fast and fail often. Keep things that aren’t fully understood from going out the door. Prevent unintended consequences. The point of the test is there is an input and an output with something in between. Code coverage is great and all – but outcome coverage is better.

Scenario 5: False Positives

“Hey Lacey, why so down?”
“Oh, hi there Steve – looks like the pipeline is blocking me again.”
“Again? Really? What is it this time, Martians?” Lacey slightly smiled at that – Steve was always trying to cheer people up.
“No”, she replied, “It’s the functional tests. They take forever to run, then they fail for non-issues. I don’t know if I can even trust them, they fail so often on false positives.”
“Yeah, I know what you mean.”

Lacey and Steve are running into the problem of false positive fail* cases. Often these are environmental. They largely stem from ‘catch all’ style testing. Instead of building out tests at the functional, then the integration, then the GUI level tests** – someone has decided an end to end test is sufficient coverage. While End to End tests can be a great catch all for problems. They are expensive to build, more expensive to maintain, and downright frustrating to troubleshoot. They lead once again to Emergency Response heroes.

*(Scenario 4 also covers false positives but in regards to passing when they are supposed to fail)
** (see the Testing Pyramid)

Confidence Unleashed

Testing is an incredibly powerful weapon in a developer’s arsenal. Most recognized for keeping ‘live’ code safe from bugs. It’s hidden Easter egg feature is developer confidence. Building a great unit test suite doesn’t drive business value directly. But, I suspect – given a study of Dev workspaces – those with good testing environments lead to improved developer confidence. This in turns leads to increase productivity. Less bugs, improved productivity? A development team would be wise to implement good testing practices.

Dev Profile: Emergency Response Hero

Someone just noticed Production fell over. Ops is looking into the situation. Devs are looking into the situation. Dev Managers are hovering – the situation is tense. In terms of the Restaraunt Analogy – Someone sent the wrong dish to a customer, and the kitchen is trying to recover. Enter the Emergency Response Hero (EMH)! With one look at the problem – he asks a few questions – fly’s through recent commits, check configs, and quickly ascertains where the problem is. Without telling anyone – he jumps towards the fix – and lets everyone know, “Hey, I’ve got it. Here’s the problem. Here’s a fix!” The fix goes out and all is well with the world. Until the next emergency. Everyone lauds the hero with accolades! …and the person responsible for the initial issue hangs their head in shame.

In the real world – as opposed to the world inside a development shop – Emergency response heros save lives every day. Natural disasters and accidents are common. We live in a chaotic universe. We need and appreciate our Emergency personnel for good reason. But what about a controlled environment? It’s a great thing to have someone capable to recover quickly from an issue at hand. However, there comes a point where relying on emergency personnel all the time is a problem.

Do you have someone in your team that wear’s a fireman’s hat (or equivalent) to work?
Do you have someone unable to complete and planned work as they are always saving the day?
Do you know a dev that gets more accolades then anyone else – but not for innovation but rather fixing things?
If you answered yes to any of these, you might be working with an EMH.

Working with an EMH can be rewarding for a dev manager. But, at the same time, they can demoralize the crew. Some will respect his accomplishments. Others will be ambivalent – and others, hard workers that don’t get accolades, will be jealous. When people become jealous, they become demoralized. Then productivity falters. But how to avoid this? Personally, I recommend better Automated Testing. A highly visible EMH is a strong indicator that Automation is not doing its job. Try to get ahead of this curve before it is too late. EMH’s get burned out too.

A day in the life of a Computer Science Major

If you’re wondering what declaring a C.S. major will look like – read onward. Turns out, you’ve already figured out you want to work on computers, not toilets. No offense to toilet fixers, but it’s just not my cup of tea. The same goes for doctors – it’s great they save lives, but, there’s just too much trauma involved. Well, you’ve made it to school, college, university, pick your name of choice. And here is what a day in the life of a computer science major really looks like.

You go to class, like everyone else. And if you’re at a liberal arts college, you got to the same classes as a everyone else. There’s only one or two classes a semester you really care about – the other classes are all just ‘there’ as part of the program. So we sit through the superfluous classed, get down enough information to pass whatever test it is, then hold out for the interesting class that involves some kind of coding. Pretty similar to anyone going to a credit filler class.

Now, it’s time for a real class. Professor gets up, starts off with a crazy story about how his commute was <insert generic story here>. 5 minutes later, everyone has straggled into the classroom. The talk now shifts to a Q/A session – quickly followed by a round of projected code – then 20 minutes of the class trying to do what the professor asked. Homework handed out, and that’s it.

Now, some C.S. majors take the down time for doing the assignment. Most skip and hangout, watch trending and relevant stuff – or play games. The gamer stereotype has slowly been fading – but it is still quite prevalent. In other words – a C.S. major has pretty much the same college life as any college student – it’s just the extra curricular activities not covered here that are truly different.