Imparting Knowledge And Preparing For The End Of A Contract
In this blog, I share an example of a consulting engagement that required significant knowledge transfer to new hires. We detail an approach for teaching Spring Batch to developers with no previous experience in Java or the Spring Framework.
The goal is to provide a real-world example of closing a contract, imparting knowledge with the client and their employees, and the potential issues faced in the process.
The Nature Of Consulting
As consultants, we are often brought onto a project to design a system, lead a team, guide a renovation, or to simply help write code. Sometimes we are brought on to debug, sometimes to mentor an up-and-coming group of developers. The customer trusts our knowledge and experience and expects professionalism.
Although some customers would prefer to have consultants on staff until the end of time, various situations arise that prevent them from doing so. As consultants, we are generally working with a client for a time-boxed duration. This generally works out well considering as a Keyhole consultant, we generally prefer the variety found in consulting rather than staying as a permanent employee.
Our goal is to leave our client teams with the right knowledge to manage their own systems and applications. Often this can mean the customer might want to replace us with a permanent hire once the contract has been completed and we assist them in getting up to speed prior to our departure.
The Other Side Of Consulting
As a consultant, it’s a great feeling to provide the solutions to a company that allows them to meet goals.
Knowledge transfer is one of the key tenets of Keyhole Software. As the saying goes “Give a man a fish and he eats for a day, teach a man to fish and he eats for a lifetime.” One of our goals as consultants is to provide a customer with the ability to walk on their own two feet. Imparting knowledge is an important part of consulting.
Recent Project Example
My most recent Keyhole consulting project has focused on modernizing a mainframe system into Java using Spring alongside a pair of Keyhole employees. I was personally tasked with the Spring Batch side of things, helping rewrite and schedule the mainframe batch processes in the distributed world.
As I developed, I kept detailed documentation and notes on what I was writing and who I was working with. I made sure my code was clean and readable. As somewhat of a recent graduate myself, I was grateful when I stumbled across code that was well written – I was deep in the bowels of a complex system.
Bringing Everyone Up To Speed
As we neared the latter half of the development initiative, we were tasked with training a small group of new hires fresh out of college who would be “taking over” the application after our consulting engagement for the development was complete.
Once I received the news that new hires would be coming along, I started detailing a teaching plan. I was told that two of the employees would be taking over my batch work. I had about two months to brain dump everything I had learned and done in my year-long stay with the client.
I began a teaching plan that followed this simple pattern:
An Overview of Our Goals
When I was introduced to the team, I started by establishing our goals and what the expectations were. We focused on how the workflow and communication process with the team would transpire throughout the process.
Together we analyzed Job Control Language (JCL, the scripting language on IBM mainframes that instruct the system on how to run a batch process or start a subsystem). The JCL would define job steps, FTP parameters, and more.
We covered M204 modules that have gone through a code grind process, resulting in an equivalent Java program. Analyzing the renovated Java code against the original M204 was a common occurrence. Smaller M204 modules were handed to us as fresh rewrites – often times this requiring further analysis and a deep dive into the scary world of M204 code and syntax.
We discussed that once we developed the Request Mappings in a Controller as an endpoint to kick asynchronous batch jobs, the only thing left to do is create a Setup Tasklet and Batch Configuration to wrap around the renovated Java module.
This is the bulk of the knowledge I sought to transfer to the new hires.
Paired Programming Exercises
After the new developers had a clear expectation of our goals, I would then connect to a projector or external display and write code that they could follow along with. This helped to familiarize them with development flow, testing, and deployment. Writing code together allowed the developers to ask questions or pause when a subject required a more detailed explanation.
The employees would code along as we defined Batch Configurations and set up the job steps. We also worked on defining helper
@Beans and wrote out the necessary setup components in the Setup Tasklet.
Our job definitions resulted in a package named after the original job, BUSBSPA for example. Within this package, we would have the Java module, such as B.BUS264. Then we would write a
Bus264SetupTasklet.java and a
Bus264BatchConfiguration.java class, respectively. This step has the potential to be the most challenging, in my opinion.
While a consultant may feel comfortable in the code, a new hire may feel frustrated and discouraged. New concepts and frameworks will feel like large obstacles, and conquering them together is important. To overcome this communication breakdown, it’s imperative to slow down and think like a novice.
It can be helpful to stop and ask things like:
- What does this line of code DO?
- Why won’t this compile?
- Do I NEED these
@annotations at the top of my files?
Things you may never think twice about can be major roadblocks to a newcomer.
Eventually, the new employees were set to begin writing their own batch processes, using the mainframe code and my previous work as guiding examples. However, I was always available for questions on particularly sticky problems and outliers.
Often times the team would run into snags when comparing FTP’d files between the M204 and Java run. The client was insistent there were no differences, even if the difference was minor formatting problems. This took quite a bit of finesse and patience.
We ran into another issue with jobs that updated, added, or deleted records, ensuring the data was the same in both directions. Given that this client was using both the Java renovated project and the M204 project simultaneously, they implemented a ‘circle of life’ process to keep both environments in sync, with M204 being the system of record.
Fortunately, we were able to work through these issues and after a few sessions of paired programming, the developers were ready for the next step.
Finally, the employees I had been training were set out on their own. They had seen a batch program fully implemented from the old mainframe code into Spring Batch that was then tested, deployed to production, and added to the scheduler.
Prior to this system, batch development was like the wild wild west to this client. No rules, no structure, no development priorities to be seen. When the team was tasked with this assignment, we worked together to create an Agile development cycle. I implemented a physical scrum board, planned out sprints, and wrote sticky notes to track development.
Even though the developers were on their own now, there was still the existing code base to examine for working examples, and a team around them to answer questions and provide gentle nudges in the right direction.
When teaching or imparting knowledge as a consultant, there are occasional speed bumps along the way. While solving targeted technical problems, it was often difficult to describe goals and expected outcomes to new hires that hadn’t had time to become familiar with the codebase. Patience and understanding are key when it comes to getting ideas and concepts across to another developer, especially one that has recently joined a team.
Another challenge was time management. Some clients may expect you to impart knowledge while simultaneously working on technical tasks. This requires you to remain focused only on what aligns with your goals while on-site. I believe this also requires you to look at multiple phases ahead of where you are in a project.
A good consultant should understand the extended effects of a project in concurrency with a project’s current roadmap. Avoiding technical debt and passing down this awareness is essential to keeping clients happy.
This experience is gratifying and a great way to end a consulting engagement. Taking a step back from the code and becoming a mentor or teacher is an eye-opening experience, especially as someone that has spent most of their time as a student.