Blog

Code Reviews for the Bottom Line

Posted on by Jeff Marino

Executive Summary
The users of your software don’t care how good the code is, only that it allows them to be more effective in the job that they are trying to get done. Code reviews don’t necessarily prove how effective software can be, only that it follows some internal standard. There are other ways to get to the same result by automation that will not be as “in your face” to the person being reviewed. This doesn’t mean that senior level peeps shouldn’t help junior levels but there are other, more constructive, ways of doing this; lunch and learns, mentoring, online gamified training, ect. By time spent by people reviewing code, developing using common standard static tools, and shared frameworks, goes right to the bottom line. Plus the code gets better, the stress of reviews go away, and all developers can be more creative and stumble upon the “right” thing quicker. It’s all about getting to the “right” thing for the users of software as fast as possible!

Developer Story
For a developer there may be nothing more stressful then having peers inspect and scrutinize their code. In most cases the need for manual inspection of code can be replaced by automation and better development methodologies. Unit / load testing can help point out bottlenecks and verify that the code is doing what it’s supposed to do. Standard coding styles can be enforced by static analysis. Advanced coding techniques can be encapsulated within abstracted frameworks that simplify and enforce common usage. Instead of saying that all should use try / catch / finally / log, build some utility classes that use the strategy pattern and have everyone use those. Enforce that every public method, especially api / service entry points, adhere to this usage via static analysis.

Confidence Fosters Effectiveness

Posted on by Jeff Marino

Software developers can only be effective to the extent that they are confident.

Continuous Release
When the certainty of successful production releases is not always 100% a team may tend to hold back a bit and not push for the release. Who would really want to rush into a release knowing that there is always a few days of stressful issues after the release. By using automation and releasing often this stress level will go away and that mental energy spent worrying and that physical time spent fixing will be able to be spent on finding the right solutions to problems.

Testing and Coverage
Not knowing the impact of a code change can have far reaching affects on the team. You will not only feel like you’re playing wack a mole with software bugs but you will also not be inclined to make the best architectural decisions. Who would want to refactor a hunk of code when there’s no way to tell what the impact will be, you may end up fixing a bug in the code that is treated as expected behavior by the users of the code. The importance of automated testing is not only to meet some methodology standard but is really to install confidence, allow easier and less impacting changes, and to remove wasted time and energy from the process.

Symbiotic How and Why

Posted on by Jeff Marino

I once heard that those that know how always work for those that know why. After thinking about this for a bit I realized that those that know why could never achieve anything without those that know how. When it comes to software the “why” folks are the business guys (executives, product owners, etc.) and the “how” folks are the tech guys (scrum masters, developers, QA specialists, etc.).

The business guys don’t necessarily care “how” it gets done, only that it actually gets done and as fast as possible. They are looking to address specific revenue related business concerns The don’t care about software methodologies, frameworks, patterns, and architecture, only that the software does what they need it to do. The end user of the software doesn’t care if an agile methodology was used, or what java script library was used, they only care that they can be as effective as possible in using the software.

As product owners we’ve all been there! When will it be done? Why is it taking so long? Throw more bodies at it! Have the current team work extra hours. This point of view from the top, especially over a prolonged period of time, will create shoddy software, lower morale, and cause turnover. All outcomes are not good for the organization as a whole and will wreak havoc on the long term sustainability of a software product.

The tech people don’t necessarily care “why” it needs to be done, and sometimes don’t know 100% how to actually do it. A technical person will know what framework to use but when given a vague list of what the software should do it becomes extremely difficult to interpret these “requirements” and implement the right thing.

As developers we’ve all been there! A vague list of steps that the user needs to take with no real understanding of what the actual user’s goal is; show this screen, allow them to press this button, require them to enter this info, show this list of things. I’ve seen instances where product owners feed the instructions to the developers piece meal over several weeks, imagine trying to build something good and not knowing what you are building until it’s done, how can it be good?

Some of my greatest memories and most successful implementations were when the business and tech guys were totally aligned, when the developers knew more of the “why” while they designed and built the software, and when the leadership vision of the organization was to create the right software for their users and customers.

Building a team like this is not easy but it can be done. It requires change from both the business and the tech guys, and it requires trust. Trust that the technical people can make delivery schedules, that the software will meet the goals of the business, the users will be able to get done what they need. The technical people need to know that the business has their backs, that the business wants to develop a good product, that the business actually cares about the customers.

There are strategies that can be implemented to help both of these groups get closer, build trust, and become the well oiled machine that they need to be. By improving the processes used to design, build, and distribute software these teams can start to work together.

Here’s a short list of ideas that can help make things better:
1) Allow software to be deployed as fast and as often as possible, if you have a SAAS product or the like this is easier than you think. If you have an internal line of business app this is a little more difficult but the same principles apply.

2) Take the time to do more automation; testing, building, releasing. The more you automate the less manual risk you have. There’s a small up front cost but the ROI can easily be shown when applied to a period of time. 1 week overall, not consecutive, up front for a 4 month project is nothing, you will gain the 1 week of time back with more releases, less debugging of issues, less production troubleshooting, and less customer service issues.

3) make the desired result of the software or feature known to the technical people. The more these guys understand what the desired result is the better they can make the software both architecturally and usability wise.

Darkness Can Enhance Vision

Posted on by Jeff Marino

Organizations sometimes face the challenge of maintaining software used for the tactical day to day operations while at the same time they are trying to create new software that will strategically help the business. When using the same team to do both tactical and strategic development the chances of the strategic development actually being any good are slim. If time and budget are not a factor then the strategic development will have a chance of success but will be extremely late and over budget.

The crux of the problem is that the context switching between tactical and strategic will blow timelines and budgets, along with limiting the effectiveness of the team in creating something that is actually good. When the tactical work takes longer, which it always does, then there will be less time for implementing the strategic ideas. Limiting the time needed to create the strategic software will result in the cutting of corners, shoddy work, and software that is just not well thought out and easy to use.

To be strategic, tech teams need time to think of the bigger picture. It’s extremely difficult for them to create something good because they are always in the weeds. When you add the need for them to think tactically and strategically at the same time then they are required to be in the weeds in multiple gardens.

Understandably, some organizations won’t have the resources to spin up a brand new isolated team to work in a vacuum on the strategic software. For these folks there should be at least a single high level technical / business person working on the new software all the time. This person should not be involved with any day to day tactical, ever, and should be considered to have gone rogue. A conversation here and there to get advice on tactical projects will work, as long as they are scheduled ahead of time. This single person should never implement anything tactical unless it has to do with laying ground work for the strategic software.

For organizations that actually have the resources to spin up a new time then go “dark”. Start the new team, put them in a vacuum, take them off the grid, go rogue. Whatever you want to call it, treat the strategic software like you would treat a startup, following all the normal agile, MVP, fail fast principles that you read about.

Over the years I’ve witnessed some failures. In some cases not matter how apparent it is made that the strategic software will not be completed unless the team goes “dark” the organization can never get out of it’s own way and let the thinkers think. In the end most organization will spend an inordinate amount of time and money for nothing, failed projects are the norm. The kicker is that sometimes the “tactical” software is never even used because the organization is going so fast and is so immersed with putting out fires that they aren’t able to think through what they are actually asking for. This is why the tactical software takes longer, this is why strategic software is treated like a second class citizen.

I have also witnessed some successes. Where a single team is left alone to do what they need to in order to create something great. When a team has the organizational backing to just create something great and the time to spend thinking about what needs to be done then lightning will strike. The team will be a well oiled machine, the software will meet or exceed expectations, and the strategic business goals will be met. By going “dark” them team can actually see and build the vision of the organization.

I recently spoke with a friend of mine that worked at Comcast. I was sharing with them how much I liked and admired what Comcast has done with the X1 platform. He told me that in order to accomplish their goal of reinventing the platform they had to spin up a separate team and treat it as a startup.

When you step back and compare the failures and successes you will see some things that you wouldn’t expect. The cost of spinning up a new team and actually meeting the strategic business goals will be less expensive and more successful than trying to have a single team juggle all the balls. When you look at only staff dollars for the single team, the cost will appear cheaper on paper.

It would take many successes and failure for an organization to see the benefits of going dark, some stumble upon it by accident, and some are advised to just do it.

Automating Tests for Quality

Automating Tests for Quality

Posted on by Jeff Marino

Releasing software without automated tests can and will have a negative financial impact to your organization. Software will be more expensive to develop and maintain, your quality will diminish, and software updates will take longer and longer to get released.

Automated testing will also help mitigate risks associated with buggy software that can cause negative user experiences or customer service issues. Plant floor operators that can’t work because of an app crash, limo drivers missing the pickup of a VIP customer because their logistics app didn’t display important data, and online retail customers that couldn’t complete their order because of an untested scenario. Any of these scenarios can cause significant loss of revenue or increases in operations costs.

To be fair, automated tests will not solve all your problems and are only as good as the scenarios that the developer was able to think about ahead of time. But, as the software evolves, so do the tests. This is the increasing payback from the ongoing investment in automated testing. When done correctly, as new bugs or issues are found they would be documented and codified within the ever growing suite of tests.

Automated tests are not a panacea, organizations would still require some level of manual process to verify certain aspects of the software; user interface behaviors, animations, and anything else where only a human eye can be the true judge. There have been technical advances in this field as well but that topic is beyond the scope of this discussion.

Organizations sometimes choose not to support automated testing because the extra time needed to write the tests doesn’t provide an immediate ROI. When developers lack the strategies required to design testable code they will take longer to develop the testable code, at least initially. This is the perceived waste of time. But, like everything else in life, it is a phase that will pass. The duration of the phase depends upon the skills of the developer and the patience of the organization. When the skill of writing testable code is nurtured, then the tests will be the foundation from which your your high quality software is built upon.

One of the other major concerns with automated tests is that if they are not kept up to date then they become hard to maintain over time. This will occur when the tests are a lower priority than the main application code. When the test code is treated at the same priority as the application code then they will be kept as up to date as the application code, and will evolve the same as the application code. Again, there are strategies that can help with this from a developer perspective.

If I had my way developers shouldn’t ever ask if the organization wants automated tests. They should just be writing them as part of their normal day to day application development. When the automated tests are treated as a second class citizen they are looked down upon and pushed down in the stack of priorities

I get some of the reasons why an organization wouldn’t see the value in automated testing. Some can’t justify paying for code that isn’t explicitly usable by an end user or customer. Some would argue that the time spent on developing the tests would be better spent on developing features. I could go on and on… but I won’t!

I am a big proponent of automated testing and believe that in the long run it will actually save your company some money, there’s a return on your initial upfront investment of getting this process in place. The more you invest upfront the bigger the payback.

As your software product evolves and grows your developers will be able to make changes throughout the application code with confidence, they would just have to run the tests and see if they introduced any bugs. Sometimes it takes a bit to get all tests to pass, but better found during the development process as opposed to QA or production; the further away from the development process a bug gets the more expensive it’s impact, and the longer it takes to fix.

The following is a somewhat fictional story of Jack the developer and how automated testing changed his process for developing applications.

Jack’s Testing Journey

In the beginning, Jack would test his applications by manually poking at the user interface; pressing buttons, selecting items in lists, and entering text. For Jack, if the application didn’t crash then it must be working correctly. Jack would always run the application within the debugger and manually step through code, look at data points, and visually validate the state of the application after each interactions.

This process that Jack followed would force him to take a long time to deliver features. Many developers follow this process when creating the latest user interface based web, mobile, and desktop applications. The bigger the applications and the more developers working on it the quicker this process breaks down.

After many delayed releases and quality issues Jack eventually tried to figure out a better way. Jack started to separate the user interface specific code from the business logic code. He then learned that the separated out business logic could be housed within a command line application at the same time.

Jack could now write some code within the command line application that would mimic the user interface but not require all that clicking. He could then orchestrate his business logic in different scenarios using different sets of data and automate the series of tests. He would still use the debugger to manually validate things but he didn’t have to do all that clicking around in the user interface to get to the part that he wanted to test.

Once Jack started developing his applications this way he found that the separation of user interface and business logic allowed him to make changes quicker because of the better designed code. Because it was easier to run the automated tests he was writing more of them to validate edge cases and exceptions within the application. Overall Jacks quality went up and his releases were faster.

Jack then discovered testing frameworks, and his world really opened up. Instead of writing command line applications he would write a test application that would organize all his tests, allow him to run from the command line or IDE, and could give constant feedback as he coded.

Jack was finally able to kick the manual debug steps but coding the logic to assert state and data right within the test itself. In some case he had to redesign his code yet again to enable the ability to assert certain things within the application. These redesigns led to a better designed application that was easier to change.

Jack’s process didn’t change over night, it was a little painful, and cost the company a little extra time and money as he got up to speed. But, as Jack’s skills increased he was able to save the company money by cutting down on bugs, releasing features quicker, and providing higher levels of customer satisfaction

Summary

Developers should never have to ask automated tests are desired or if they should be delivered with the application being developed. Developers should be creating tests as part of the code writing process. If they have to provide hourly estimates they should include the time to write tests and design the code to support testing, but not specifically call out tests anywhere in their estimates. If developers get questioned about why they took the time to write tests, their response should be that the writing of the tests is how they’re able to deliver higher quality features faster and with less risk to the business.

When I release a piece of code I want to tell the stakeholders that it WILL work, not that it SHOULD work. It is my responsibility to mitigate any risk to a company by delivering the highest quality code possible.

Passionately Detached

Passionately Detached

Posted on by Jeff Marino

As a business owner my passion is to help organizations create more effective software while increasing their bottom line. This is not an easy task, just saying “change this one thing” doesn’t mean that all that are involved in that change are on the same page. Even just changing one thing will require several attempts to get everyone on board and find the idea that will actually work for the team and the organization.

In order for me to be successful in helping an organization I have to be able to offer up many approaches in hopes of finding the one that will resonate with them and make the change they are looking for. Each idea is a step to the final outcome and not all ideas are successful, some will fail. In order to get to the desired result you have to be willing to fail, and maybe even fail a lot. The only way to be truly successful is by not being afraid to fail, learn, and move on.

By detaching from each approach, but at the same time being passionate about the outcome I am able to easily and unemotionally fail. Finding the right software approach is like chiseling David from the stone, it always existed, you just have to be willing and strong enough to get all the bad approaches out of the way.

Organizations usually suffer from the same inability to detach as the rest of us. Executives are tied to what has always been done, managers are tied to process and afraid of change,

As a software developer, I am also able to accept failure in order to write great software, create effective user experiences, and provide solutions that meet and exceed business objectives . This process is one of evolution; create, test, get feedback, change, rinse and repeat.

Great software can only occur by listening to great feedback and remaining passionate about the final business outcome, not by being passionate about the single piece of code that was written. The fact that I think that a screen looks good or that the code is clean has nothing to do with the actual problem being solved. When the users see it and say looks good but doesn’t do what I need it to then what good have I done? This is the point where detachment is important, by removing the emotion from what you created, actually hearing the feedback, you can be objective in learning what is actually needed.

When working on a team it is even more important to detach so that all can be objective about listening to feedback, issues, and problems. As a detached unemotional team it is way easier to make a change since it’s just a change and nothing personal against anyone. I’ve seen developers get aggravated when someone changes “their” code, I explain to them that it’s not “their” code, it’s the contribution to the bigger whole. Developers are usually very passionate, and sometimes they treat the code as their baby. Addressing these situations usually just requires a more open relationship among developers; paired programming, code reviews, and the removal of single owners from any piece of the puzzle.

When the development process requires that all developers work on all things, the attachment to a single thing is removed and the developers can concentrate on the overall solution.

Please Stand Up

Please Stand Up

Posted on by Jeff Marino

In agile they say that you should organize a daily 5 to 10 minute meeting to review status, discuss issues, and bring the team together (https://en.wikipedia.org/wiki/Stand-up_meeting).

My first piece of advice is don’t do it just because the methodology calls for it.  Just because someone is certified in scrum or the like doesn’t mean that this practice will actually help the team.

On too many occasions I’ve seen this turn into a plain ole status meeting where each person drones on and on about what they did yesterday and what they are doing today. Most likely you have a process in place to view tasks (kanban, jira, Azure Dev OPs, etc.) so what someone did and what they will be doing should be pretty apparent.

Some people don’t like speaking in large groups so this causes anxiety which is counter productive in what the meeting is supposed to achieve. When this is done with remote teams it’s even more painful because everyone is sitting on a Skype call and most are just “back grounding” the speaker anyway.

Having the stand-up as the first thing you do in the morning is also counter productive. Some of my greatest thinking is done in the morning, in the shower, or on the drive into work. The last thing I want to do is be side tracked when I have a flurry of ideas with a group discussion that I can’t possibly give all of my attention to.

If there are impediments that need to be discussed then bring up directly to the scrum master, lead developer, or whoever would be in charge of helping.  Discuss with the specific team members that can help come up with a strategy and then send an email or assign a task to the leader to solve the problem. With a public list of impediments / tasks for the management clearly visible then they will also be accountable and that task will be a dependency in completing your task.

Teams are not brought together by a shared and unified vision, not by forcing everyone to speak in front of a group. Remote teams are hard to manage, having people talk on the phone about their status is not going to bring them closer. Perhaps organizing the work so that multiple people have to work together to implement a feature, this fosters camaraderie.

If you are mandated by management to have this stand-up then opt to have it in the afternoon or during lunch. Treat it more like a coffee break as opposed to sidetracking everyone first thing in the morning. As the owner of the meeting be sensitive to those that are anxious about speaking in groups, coach them and try and help them to be less worried about what people will think about them.

Inefficiently Effective

Inefficiently Effective

Posted on by Jeff Marino

Being effective does not always mean being efficient.  Sometimes it takes longer to prepare for an infrastructure change then to actually do it.  When the change is extremely critical then it pays to take the extra time to script it as much as possible.

One of my bigger clients was recently doing an acquisition transition and they needed to migrate a Microsoft SQL Server database from one server infrastructure to another.  This database migration was a small part of a bigger event that required a company wide downtime during the migration, this meant no customer bookings and an operational blackout.  Any delays could result in loss of revenue, service incidents, and possibly even a loss of multi million dollar accounts.

I was not directly involved during the preparation and at the the beginning of the migration process, I did eventually get a call after they ran into an issue.  The migration should’ve taken fifteen minutes but over an hour later they were struggling with what appeared to be a corrupt backup file.  

The team had previously, manually, tested this same set of actions; backup the database, FTP it from an external server to an internal server, then restore the backup.  It always worked!

During the actual migration they ended up using a different server to FTP the backup from, resulting in a corrupt backup file on each attempt.  They tested various other scenarios and eventually found that they were using ASCII transfer instead of BINARY, and of course BINARY was the default setting in the environments that they used when testing.

The two hours of down time that it actually took to transfer the file made it quite apparent that a scripted approach would’ve made the world of difference.  In this case the client was lucky as the event occurred at a low volume time.  There was minimal revenue impact and no service incidents.  Whew!

The moral of this story is that even a one time transfer of a file can benefit from a little scripting love.  It would’ve probably taken the team member an extra half hour to write a script, but it would’ve saved two hours of troubleshooting time, eliminated undue stress, and would’ve nearly eliminated any loss of revenue.

Scripting a simple one time FTP action may sound like overkill but in the case of a company wide downtime you should limit the risk of failure as much as possible.  Limiting the risk can only be achieved by confidence in the tasks at hand.  Having a scripted approach to a task builds confidence as there are no manual steps to remember or document – just run the script!

Yes, during the planning phase it would’ve been less efficient to write the script.  But during the execution phase, the time during the actual migration, the effectiveness of the team would be immeasurable.