My first major college project was in the summer of 2004. I was trying to build an encryption/decryption device as per the then newly released Advanced Encryption Standard. I failed miserably.
I had about 2 months to complete the work. In about 2 weeks, I proposed a design which greatly impressed the people guiding me. Thinking myself smart, I felt I would be able to complete the actual implementation in a month and spend the remaining time on something else. I got coding and implemented the essentials of the design within a few weeks. But the performance was awful. After trying to debug it myself for a few days, I asked one of my supervisors for help.
He was horrified to see my work. Most people would work for two days and get their work reviewed. I had tried to finish almost everything and then show it. He found my code unreadable. Finally, by using the techniques he told me, basically breaking up the whole design into smaller logical blocks and checking the performance of each block, I was able to find the cause of the problem. It was the last place I would have suspected. It wasn’t one of the complicated logical units, but a simple shift register, a lowly, 1st year engineering concept which I was using badly.
The whole design had to change. Again, I rushed through the implementation and again, I found some other issues. In all, I re-did the whole project 3 times and the project still did not work properly at the end.
In my job, I found the same problem again and again in so many young graduates fresh out of college. It is often the slow approach that is quickest. Speed in engineering is not about how quickly you can build something. It is about not having to re-build anything. Taking time to work through problematic scenarios, building in test cases at every stage can drastically reduce the overall time to stabilize a product.
The problem is that culture is often contrary to this. Even technically inclined managers frown on deadline over-runs and also, well sometimes engineers just feel lazy. It is taken for granted that implementation can be quick and then some time will be taken to stabilize and de-bug the product. The problem is that the debug phase is invariably longer than anyone anticipated.