Getting The Test On Monday (Written By Dawn Baker, JD Edwards VP of Development)
By Kem Butller-Oracle on May 13, 2011
May. Here in Denver, the month brings spring fever and for many semester-worn students…the anxiety of final exams. Hopefully those students had instructors this year with the same habit as one of my college professors. In his helpful (but somewhat annoying) way, he stomped his foot twice when a topic was going to be on the final exam. Naturally, we vigorously highlighted that section in our notes… (and a few students woke up to at least catch the end of that lecture).
Awhile ago, our Oracle JD Edwards engineering team decided to take a lesson from that professor. It started with discussions on how to reduce the churn occurring late in the development cycle. Great ideas for improving the code surfaced during system testing when they are difficult and expensive to implement. Comments like “I didn’t think you were going to run it that way” drove incremental work to get an optimized solution. At that time, we already had a robust development cycle that connected solution requirements through testing and back. But no matter how well-executed, multiple handoffs by nature leave small opportunities for re-interpretation…the classic “telephone game”. A change seemed in order and during one of musings came the flashback to that helpful college professor – “it’s like the professor is offering us Friday’s exam on Monday, but no one is raising their hand”. A-ha…let’s get the test on Monday.
While test-driven development is not a new idea, thinking about the end of the process first helped re-frame our development model in several positive ways. By starting with the end in mind, we were able to drive extreme clarity around the solution early in the process which improved the ramp time of the team and drive the optimal ideas to the front of the cycle. But test-driven development was only part of the answer. We also found ways to drive ambiguity out of the solution early on by documenting the tests in a clear, structured method. And finally, we tapped into one of the unique strengths of the JD Edwards team – collaboration. We overlaid the process with a heightened collaborative model that minimized the hand-offs and indirect communication that cause scope drift.
Simple changes…but combined to produce positive results: Better visibility and less churn on the back-end produced more consistent on-time delivery, less rework, and more confidence around the completeness of the solution before testing starts.
But whether these methods produce the same results elsewhere is not as important as the reminder that we all need to be “students of our experience” -- continually looking for new ways to solve old problems. In the same way that we acknowledge standing still on technology brings risk of lost opportunities, we also need to keep innovating the ways we build those technology solutions. JD Edwards is fortunate to have a depth of experience that is continuously introspective about how we can improve our products through better engineering… innovating product and process together.
To those students still cramming for those finals – all the best. Those of us at Oracle’s JD Edwards are getting the test on Monday…at least for this week.