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.
To some degree that circle of development never ends. You are making your perfect version for today's requirements. Your replacement 3 years from now will have their own style and opinions as well as new requirements. They might feel the same way about your code then as you do about your predecessor now. Some code is absolute crap, but most of it is is all very subjective. The simpler the code the better if you ask me!
Agreed - the irony of that cycle isn't lost on me! These predecessors did some amazing work which propelled companies forward. At the same time though, some of the work significantly held back the company in the future.
As developers we are always improving and I know my own code from 3 years ago has issues - however you're absolutely right that keeping it simple is the key. This can be helped by SOLID principles, especially SRP, and also applying SRP and SOC to architecture. And, TDD helps you to write simple code in the first place.
So back to the point of this article, caring about your code IS important - but it needs to be balanced with innovation and productivity. Your customers don't care about your tests, but they do care about how many bugs you get, how long it takes to fix them, and how quickly you can add new features!
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.
For some kinds of apps and situations, unit testing is an absolute requirement. I totally agree. I've had apps myself that there is no way we could have made code changes without unit tests of the very complex business logic.
Everything in software development depends on the use cases.
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.
To some degree that circle of development never ends. You are making your perfect version for today's requirements. Your replacement 3 years from now will have their own style and opinions as well as new requirements. They might feel the same way about your code then as you do about your predecessor now. Some code is absolute crap, but most of it is is all very subjective. The simpler the code the better if you ask me!
Agreed - the irony of that cycle isn't lost on me! These predecessors did some amazing work which propelled companies forward. At the same time though, some of the work significantly held back the company in the future.
As developers we are always improving and I know my own code from 3 years ago has issues - however you're absolutely right that keeping it simple is the key. This can be helped by SOLID principles, especially SRP, and also applying SRP and SOC to architecture. And, TDD helps you to write simple code in the first place.
So back to the point of this article, caring about your code IS important - but it needs to be balanced with innovation and productivity. Your customers don't care about your tests, but they do care about how many bugs you get, how long it takes to fix them, and how quickly you can add new features!
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.
For some kinds of apps and situations, unit testing is an absolute requirement. I totally agree. I've had apps myself that there is no way we could have made code changes without unit tests of the very complex business logic.
Everything in software development depends on the use cases.