Pitfalls of Applying New Methodologies
Yesterday I was having a discussion with one of my senior delivery leads and we were talking - amongst other things - about "How an organisation applies new methodologies and the pitfalls that this sometimes has".
This made me remember a story from my very early engineering days. I was a relatively junior engineer at Bell Northern Research, in Ottawa. We were programming using PROTEL (proprietary telecoms language) writing software for the NORTEL telephone switches (DMS-100).
At some point around 1993 (OMG, yes we did have computers back then) the company decided to switch development onto C++ which was the new hot cake. So we bought books, we did training and we started developing new software on C++. After a few months the first integrated s/w was ready for test...and guess what...
The phone call took something like 5 minutes to complete....5 minutes...it normally takes milliseconds...Panic! why did it go so wrong? well, we looked at where time was being spent to establish the call and we found out that the number 1 time waster was the dynamic allocation of memory as classes were created...so we removed dynamic memory allocation, inheritance etc etc....by which time it was like programming in C (or indeed in PROTEL) and the phone call completed in milliseconds as it should...
What is the learning? Was C++ bad? obviously not...
The learning is simple: We need to understand how we apply new methodologies and we need to adjust the new methodologies in our environment and the non functional requirements that this environment brings.
...and yes, I used to write code...
Test Lead at Aker Systems | Ex-Yahoo
8 年Tailoring is the key to applying new methodology
Cloud Application Architect / External Consultant @ SG European Commission | Spring Microservices
8 年This reminded me of a time I was making a First Responder Video Annotation application running on a windows mobile 5 PDA. To make the story short, we were recording video from a remote camera but the video needed transcoding (from 3g to avi if I remember) to work in our windows mobile application. In the first proof of concept the transcoding was done by an intermediate netbook (took 4-5 seconds including transmissions). A colleague and I spent one whole night cross-compiling ffmpeg for ARM/Windows mobile... and watched in horror as ffmpeg needed 90+ seconds to transcode a 10 second video that took 5 seconds on the netbook *sigh*. Lastly, cross compiling ffmpeg involved trying out more than 10 different releases to find which source code was less broken, and we ended up hacking a few defines and commenting out sections of code we didn't want to get it to work (windows mobile was on the way out for support).