Overcoming a Technological Gap — a Horrible Circumstance or a Creative Adventure?
This is part 2 of my series on my journey of healing a dying software group. In part 1- How Can Corporations Heal a Dying Software Group?, I presented an overall scan of a dying software group I had begun leading. This time, I will dive into the technological difficulties.
My next step was to figure out how to overcome technological gaps. When I say technological gaps, I don’t mean switching from Java to Node.js, oh no. We’re talking here about obsolete systems, ancient coding language (worse than hieroglyphs, trust me on that one), an impossible coding environment, no coding methodology, plenty of spaghetti code etc. The systems were implemented in such a way that there was no possible hardware upgrade without just writing everything from scratch.
I began solving each problem separately. I found several solutions to each problem and began prioritizing. For example, the coding environment issue. The system’s coding environment was so old, that even the company that designed it had already been shut down for many years. It was designed in a certain way that even the simple things were in fact very counter-intuitive. The compilation process, for one, had to be done very carefully. In order to compile one file, a programmer had to find all the files that were affected by it, all the files it might affect and files that are somehow related to it. They needed to find all these files manually, and run them through some other processes, and then when that was finally over with- they needed to wait for a few hours for the compilation to be complete. This was the least of all problems; therefore it was the first issue to attend to.
After massive research and thought, we found an elegant solution, that was immediately applicable. We’ve found a way to automate the previously manual process through a third party application. However, an easy compilation was not the main goal here. My goal was to target all the faulty infrastructures, find and implement a simple solution yet constantly remind the client we needed more budget to solve the more serious infrastructure issues.
This proved to be a path worth pursuing, since each problem we’ve solved uncovered more issued concerning the architecture and design of the system. This project was doomed the moment the papers were signed, but I hadn’t given up hope.
I started sniffing around, trying to find an interesting project related to our system. I found a project that can solve a very serious problem and we can add it to the main system. This decision provided two things: first, the client understood there is more potential to the group than he had previously thought, and second — we could add infrastructure upgrades as a part of the new project’s budget. This had more value than just money — the developers began feeling the new spirit, they felt more needed, they began working with extra willpower on infrastructure projects since they knew it was meant to serve a project the client believed in. This led to an effective work environment, where people felt more productive and felt more inclined to share creative solutions.
At this point, you might ask — where is our DevOps team?
Well, to tell you the truth — there was no designated DevOps team, nor was there a QA team, a product manager, a proper project manager and so on. We had to rely on ourselves and to be completely honest — it was better that way. In my opinion, distributing DevOps responsibilities among team members is more efficient and leads to better and faster results than depending on an outside team to come and rescue us from poor infrastructure. By sharing the responsibilities, I made sure that when integration and deployment time came — my group members would know how to deal with issues. By integration time, they would have come to a point in their research of the code and its behavior where things made sense. Another positive outcome was a shared interest in succeeding, leading to better teamwork and shared efforts.
Each third party application we wrote made the people stronger. They felt committed to the project and wanted to do whatever it takes to make sure the system is approachable — for them but also for the next generations.
One of my developers began showing unusual expertise in DevOps related projects. I began secretly grooming him for the position of DevOps team expert. He was always excited to research the system’s code, to write manuals, to suggest improvements, to explore various solutions, to help others. He was a great DevOps mentor, our go-to guy.
Suddenly there was hope. We began solving one infrastructure problem at a time. After building a few relatively small helpful applications, we could embark on an end-to-end solution to something big. One of our big infrastructure projects was to change the work environment from the old obsolete one to the beloved Visual Studio. This project had been postponed for many years because of low prioritizing. Since we drew infrastructure on our flag — this topic now became the top priority.
This project was the perfect study case. I wanted to prove that my group was both professionally capable and had fuel to see a massive project through. These things were very important to me since the group has never released a version and people outside the group claimed the programmers to be unprofessional. My thesis was that when a manager creates an environment where every effort is put in order to reach one major goal — people would work hard to reach that one major goal. They will research, they will talk to experts and they will find a way.
The first aspect I was trying to prove, through the new environment platform porting project, was that the group consisted of programmers who had a passion for their job. Since they began working on the project, it has become very clear in a very short amount of time, that they had amounts of fuel and passion that was just waiting for the right time. They had tons of energy and they put their souls into the project. My developers began researching, came with different solutions, coded day and night — until we have decided on the proper architecture and design. This was not an easy project and we began working on it from point blank. Reviewing the code, throughout the process, made sure that programming skills were not a problem — this cleared out the second aspect of my thesis.
This project’s success had opened the group to a whole new dimension. Their professional self-esteem has begun its restoration process, and they were now very eager to prove themselves worthy to other clients.
I felt improvement, but it wasn’t the group’s time yet. They needed to fill some of the other holes they have been falling into, now and again, over the years. They needed building and empowering. We needed proper marketing, and effective software group marketing comes with, believe it or not, good software products. We needed to work on development methodologies and coding standards, on proper product management and on project milestones before we could show anything to anyone.
Overcoming the technology gap was a difficult step, it demanded many sacrifices from each group member, but it was necessary when it came to leaving the vicious zero-products cycle. It was necessary for improvement and for the upcoming products we were going to sell our future clients.
What is a group’s identity? How do we define our group and how do we create an identity when there is none?
All this and more, in my next blog post. Stay tuned :)
