As discussed earlier, I am very much interested in contributing to your company’s success.
I sincerely hope that my discrepancy with current members of lower-management can be resolved. I do recognize that your company has invested in my training and has provided me sensitive information regarding their products. I still want to continue providing a return on your company’s investment.
Please note that I have already demonstrated that I can save your company myriads of dollars per project by doing what the existing software engineering department said was impossible. I developed 95% of a feature by myself that consisted of 700 lines of code targeting business logic, user interfaces, and 76 automated tests that tested 90% of the code for that feature.
Instead of spending several minutes to get an application in a state to debug an issue, I have already demonstrated that test automation can quickly diagnose an issue within seconds. In addition, I have demonstrated that automated tests can discover breaking changes in code within a second instead of developers or QA observing the defect days or weeks later (when it’s too late).
In conclusion, I am extremely motivated to help your company produce more value in a shorter amount of time and with less money. I have made enough mistakes in my twelve years of building test driven solutions that I have become an expert on what not to do. Unfortunately, the current culture in the software engineering department does not embrace my experience and refuses to acknowledge their own growth opportunities. I sincerely believe that people with my skills can be part of your department’s 20% investment that generates 80% of the return.
I wrote that letter to HR after handing in my resignation. I was hired as a consultant on the tail-end of a doomed project that resulted in the lead developer jumping ship. The doomed project was a maintenance nightmare in which developers were working mandatory weekends for several weeks in an attempt to drive down the defect count before a client deadline. Developers stumbled over each other, modifying files that were already being modified by another developer and chasing defects that had once been resolved and then resurfaced later. These developers downright refused to write automated tests to assist their development effort. As a result, they had no clue what features they were breaking at the expense of the defects that they were attempting to resolve. QA would not even get their hands on the software until after the all features were to be constructed. Then QA would provide a laundry list of feedback for all of the software which resulted in expensive modifications coming late in the SDLC instead of cheap resolutions early in the SDLC.
At the end, everybody loss. The business couldn’t sell the software they promised. The software they built that cost hundreds of thousands of dollars was ultimately rejected by their client.
The project I worked on was very small. At most, the project required two application developers. However, for whatever reason, the project consisted of four application developers. These developers were very excited to start the new project. After all, they were coming off of a failed one. They spent close to three weeks discussing UML diagrams and the entities that they just knew would be required for the feature to be built. As they commenced big upfront design using the continuously failing Waterfall methodology, I cranked out 95% of the feature using Test-Driven Development while they were in their design phase drawing pretty diagrams and debating over entity names. The module that I wrote to implement the feature was self-contained and thoroughly tested. Every requirement identified for the feature had a unit test to ensure compliance. I implemented both the UI and business logic required for the feature and stubbed out the external dependencies so that I could test the implementation of the feature in isolation from the rest of the system.
I was very happy with the results of my effort. When the rest of the developers wrapped up their plans for the overall design, I showed them the working software that was ready to be connected, polished, and delivered. Yes, I demonstrated the benefits of applying agile practices to deliver thoroughly tested software far quicker and with higher quality than their waterfall-inspired approach. Hence, I learned overtime that clients just don’t care about the deliverables of the journey for building software. They just want to see the software ASAP so that they can make vital decisions sooner for their business.
The lead on the team just didn’t care about the efficiency of how the feature was built. He didn’t care that automated tests executed 90% of the code. He only cared about his title. After all, he was “Chief Architect” at the company even though there were no other architects in the company. The team took what I had and made modifications to the code. This was fine. However, their modifications broke the automated tests. That was bad. As a result, I sent an email that initially praised their updates. At the end of the email I requested that the team execute the tests that already exists before checking in code. I reminded them that these tests provide valuable feedback about changes to the code that will save the business time and money based on early detection of breaking changes. I thought my request was perfectly valid. After all, don’t we all want to be notified of breaking changes as soon as we break a feature? For this company, the answer was no.
The next morning at the daily standup, the lead on the team told members to disregard my request. He said that the project is small and just doesn’t warrant the overhead of tests. I couldn’t believe what I was hearing. Everybody knows that every successful project no matter how small it is will be extended with more features. These projects then evolve into complex systems over time. Hence, every small project is a seed that will grow to be a bigger one if it’s successful. Every “architect” knows that, especially a “chief architect”. So why would any stakeholder refuse to have automated tests?
To be Continued…
NOTE:
Scott Nimrod is fascinated with Software Craftsmanship.
He loves responding to feedback and encourages people to share his articles.
He can be reached at scott.nimrod @ bizmonger.net
Scott Nimrod's Blog 