How often do you think about the people upstream and downstream from you in the software development lifecycle? The following is some lighthearted advice in the area of soft skills for software developers.
When you write code you get bugs [insert test driven development argument here]. It takes time to test and fix those bugs, but realistically you can never be sure the code is bug free. Not to say that the lack of bug-free perfection is a justification for all imperfection, but it is realistic to understand that bugs are part of the software experience. Many development teams track code churn (feature work) as an indicator of how many bugs they should expect to find.
As a pragmatist, you understand the opportunity costs of each feature, improvement, and fix. Fixing bugs is important, but so is new features and shipping a release (some would argue that shipping is a feature). As a software developer, you know that you cannot always add all the features and fix all the bugs. Each feature adds bugs, and feature requests come faster than you can implement them. Even if all the developers in the world were working on one project, that project would still never be done (beyond the limitations of Brooks’s law). Sure, you would have releases from time to time, but as long as there are users there are feature requests. If nothing else then potential improvements in response to changes in platforms, APIs, and the State of the Art.
Table of Contents
Who Maintains Your Code?
There is a famous quote about writing code and thinking about who will be maintaining it …
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
― John Woods, September 1991 in the comp.lang.c++ newsgroup
Now maybe not only does your psychopath know where you live, but lives with you too (i.e. it is you!). I know if I see code I wrote more than a couple days ago I get pretty violent. The advice is still good even if you are maintaining your code, because when you are writing the code, you you are at peek understanding of it, but when so your understanding will always be lower when maintaining it. Successful code spends more time in maintenance (i.e. legacy) where it is read, then it did when initially written.
Who Reads Your Bug Reports?
When filing bug reports I suggest taking a different approach, always file bug reports as if you care for the person who reads them.
Thinking of Everyone
In practice both of these combined are the robustness principle or Postel’s law, after Jon Postel who defined it in an early specification of TCP.
Be conservative in what you send, be liberal in what you accept.
―Robustness Principle / Postel’s law
Summary
Be excellent to each other!
-William “Bill” S. Preston Esq. and Ted “Theodore” Logan
(Often attributed to Abraham Lincoln)
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
I have at least 5 outstanding bugs logged with you guys about the IDE and nothing has happened with any of them. I’ve also found out that some of these have been on going for a long time and have been reported by multiple people. Articles like this would be a lot easier to swallow if I wasn’t dealing with serious problems in your IDE every day.
Sorry, I know you’re an advocate for your devs, and I’m sure they work really hard, but I paid a lot of money for this software and the IDE has more bugs than Delphi 7 from 20 years ago.
Jon, if you can send me the bug reports I can look into them, but a better option might be to contact support and use a support instance to have support look into them.