Some great points made here and I'm inspired to think differently about my role, recognising myself as a "change agent".
However I would say that this is not mutually exclusive with well written code and that the main point of well written/tested code is in future maintenance.
I've all too often been the victim of highly praised developers who were able to implement a lot of incredible changes and features to the software. But they moved on, leaving me to deal with an absolute mess of software often so flawed that it needed completely re-architecting, let alone re-writing. These flaws became very obvious to all once these people had left. The pain and hassle that they left behind by their technical decisions after their references had been written became apparent when changes were later needed, bugs started appearing, and scalability became more relevant.
So while I agree that we shouldn't dwell too much on perfect code, we should always be considerate of future requirements and those code maintainers who follow in our footsteps.
Great article, loved it. However while I agree for the most part but writing code with TDD should not be considered as a luxury rather an essential procedure in writing code. Without TDD our product and essentially our end users suffer. We only get one shot to get users attention and TDD ensures that we value that shot. Crashes, ANR's missed cases and coverage does give you some confidence and ensures that the effort put by product is delivered seemlessly to the end users without any interruption.
Nobody Cares About Your "Perfect" Code: Change Your Perspective
Some great points made here and I'm inspired to think differently about my role, recognising myself as a "change agent".
However I would say that this is not mutually exclusive with well written code and that the main point of well written/tested code is in future maintenance.
I've all too often been the victim of highly praised developers who were able to implement a lot of incredible changes and features to the software. But they moved on, leaving me to deal with an absolute mess of software often so flawed that it needed completely re-architecting, let alone re-writing. These flaws became very obvious to all once these people had left. The pain and hassle that they left behind by their technical decisions after their references had been written became apparent when changes were later needed, bugs started appearing, and scalability became more relevant.
So while I agree that we shouldn't dwell too much on perfect code, we should always be considerate of future requirements and those code maintainers who follow in our footsteps.
Great article, loved it. However while I agree for the most part but writing code with TDD should not be considered as a luxury rather an essential procedure in writing code. Without TDD our product and essentially our end users suffer. We only get one shot to get users attention and TDD ensures that we value that shot. Crashes, ANR's missed cases and coverage does give you some confidence and ensures that the effort put by product is delivered seemlessly to the end users without any interruption.