4 ms·

> Just today, Medtronic CEO boasted that their ventilator uses 1 million lines of code. How much of this is the test code? Can requirements be traced to the cod

> Just today, Medtronic CEO boasted that their ventilator uses 1 million lines of code. How much of this is the test code? Can requirements be traced to the code and code to the requirements? I have friends that used to work in the medical device industry. Processes there are pretty strict, so it might very well be the case that they do. However, 1 million lines of code is a lot so I would still be worried about bugs. > Another example: how many projects on GitHub provide a comprehensive list of requirements/features? If you don't have a traceable list of requirements you don't know what you are building (or testing). That's a bit different. That's usually people scratching their own itch. > And, on your job: how many projects you worked on that have a comprehensive list of requirements? I don't know that a comprehensive list is what is valuable. What is valuable is being able to explain the provenance of a particular piece of code. The best way to do that is with version control. With version control, you can usually figure out why the specific piece of code was written either because: 1. The commit referenced an ticket in a work ticket database 2. The commit has an explanation for the change in the commit description 3. The commit contains a code comment or a piece of documentation that explains the change I think many people assume that they need a separate master database of requirements, and so only (1) is valid. However, whenever I've had to do maintenance on a piece of legacy code, the version control system has been my most reliable source of truth. Of course, a lot of these old mainframe systems were built before proper version control techniques were developed. Revamping them is going to benefit greatly from advances in those techniques.

Roboprog 7y ago
That certainly helps. Thank God for the “blame”, er, “annotate” command.
java-man 7y ago
Speaking of the version control. You are right: VC is indispensable tool when looking at an old (hm "mature") code base, assuming the said code base has not been converted from CVS or SVN, with commit comments like "merged from branch XX". I still think the value and importance of recording every last feature/functionality is underestimated in the industry. Granted, the tools to support this idea are largely missing - the requirement tracking must be integrated into VC and the workflow, it should have powerful search and pattern matching (this change was due to REQ#, also relevant REQ#, REQ#, REQ#...) Imagine you have a controlled and non-intrusive way to document all the features. What value does it add? 1. Testing. A feature set automatically generates the skeleton of a test plan. Test cases that are missing from the feature list get added to said feature list. 2. Onboarding. The feature list is a great place to study for a new team member. 3. Development. Given the pattern matching, the feature list might suggest related areas where a change might have unexpected impact - in addition to the usual code inspection tools, of course. The code answers the question of how, the requirements answer the question of why. 4. Maintnance. The requirements change. Assumptions and design decisions change with time. If you don't have a record of those, you have no idea why this code does what it does. P.S. and I fully agree with what you said for other points.
- Roboprog 7y ago
  Saving the revision history from the previous source control system would require reading the manual or Google for 20 minutes. I got deadlines! Of course, if the previous system is a proprietary monstrosity, it may well be next to impossible to recover the history short of writing a script to check out every step along the way and duplicate it in the new system. Ugh. Anybody who went down the path from RCS - CVS - SVN - Git without saving the check in / commit history is being a bit of a jerk, though.

Roboprog 7y ago

That certainly helps. Thank God for the “blame”, er, “annotate” command.

java-man 7y ago

Speaking of the version control. You are right: VC is indispensable tool when looking at an old (hm "mature") code base, assuming the said code base has not been converted from CVS or SVN, with commit comments like "merged from branch XX". I still think the value and importance of recording every last feature/functionality is underestimated in the industry. Granted, the tools to support this idea are largely missing - the requirement tracking must be integrated into VC and the workflow, it should have powerful search and pattern matching (this change was due to REQ#, also relevant REQ#, REQ#, REQ#...) Imagine you have a controlled and non-intrusive way to document all the features. What value does it add? 1. Testing. A feature set automatically generates the skeleton of a test plan. Test cases that are missing from the feature list get added to said feature list. 2. Onboarding. The feature list is a great place to study for a new team member. 3. Development. Given the pattern matching, the feature list might suggest related areas where a change might have unexpected impact - in addition to the usual code inspection tools, of course. The code answers the question of how, the requirements answer the question of why. 4. Maintnance. The requirements change. Assumptions and design decisions change with time. If you don't have a record of those, you have no idea why this code does what it does. P.S. and I fully agree with what you said for other points.

Roboprog 7y ago
Saving the revision history from the previous source control system would require reading the manual or Google for 20 minutes. I got deadlines! Of course, if the previous system is a proprietary monstrosity, it may well be next to impossible to recover the history short of writing a script to check out every step along the way and duplicate it in the new system. Ugh. Anybody who went down the path from RCS - CVS - SVN - Git without saving the check in / commit history is being a bit of a jerk, though.