We all have different levels of experience when it comes to coding. It does not matter if you are coding using ABAP to clean up the data as it flows through the DataModel or JavaScript to make the HTML web report come alive. Your level of experience shows itself through the code that is delivered in the solution. It can also highlight other subtle indications like; it was a rush job or you have no consideration for the developer who will maintain it after you.
One thing we all share in common is that none of us like to waste our time coding from scratch, every time. This is where the phrase ‘Google Coder’ is applicable because a quick web search will quite likely reveal a public domain code snippet that is a close match to our goal.
Time is saved because we are able to copy, paste and tweak to achieve our goal.
But was it?
Was it really?
Really?
No … it wasn’t.
The time and effort to implement the solution up to the point that the development manager is informed that it is ready, makes the developer look like a super star. Unfortunately this does not reduce the technical debt, it was just transferred over to the Test team. A lot of their time and effort is wasted only to have the delivered solution go back to the Development team.
The ability to deliver the first round of code a lot sooner only makes the development team look good in the short term. Unfortunately the long term situation just got worse and the Enterprise itself suffers because the final outcome of a fully working solution in the Production system takes longer, a lot longer. The solution is now in a game of Ping Pong between the Development and Test teams. This also introduces a lot of un-necessary paperwork and more noise in management meetings.
“Google Coding + Tweaking + Syntax Check
very rarely passes a true developer unit test”
A lot of this un-necessary frustration can eventually be traced back to the code solution that was delivered because it was not fully understood by the developer. Shortcuts were taken and not thoroughly developer unit tested before being released from the Development system.
While there are a whole range of good reasons why some code is fast tracked, ultimately, every developer has a responsibility to ensure their delivered code is working as expected … from a business point of view.
Transport Release is a Safety Check Point
At the end of the day there is a very clear line that exists; releasing a transport from the Development system is a 99% commitment to modify production. There is one question all developers should ask themselves before clicking the transport release button.
“is the code in the solution really
ready to put in the Production system?”
By choosing to deliver many code updates into the Test/User system via the Defect Ping Pong game, there is a new risk that gets introduced into the Enterprise. The ability to track and import transport requests into Production in the correct sequence just got a lot more important.
How much confidence do you have in the Enterprises Move-to-Production Transport Process? What are the implications if the wrong version of your code gets executed in production? Be afraid, be very afraid because at that point the Production data may have been updated/deleted and you will be blamed for it.
Be safe and protect the Production system from you (or the transport administrator) by only releasing transports from the Development system that are truly ready for Production.
When a transport is truly ready for Production then there is a really good chance the Test team will not be wasting any of their time and effort. This in turn means the developer shouldn’t see this code solution again, no more team ping pong. [Excellent]
What habits do I have that protect Production from me?
Further Reading: Supportable Coding in Data Warehousing.
Further Reading: The Solution to Technical Debt.