4 ms·

"Software is a form of knowledge capture. If the language (and tools) have become opaque, then the job of knowledge capture has failed." I would add that "the

"Software is a form of knowledge capture. If the language (and tools) have become opaque, then the job of knowledge capture has failed." I would add that "the job has failed". The next consultant who modifies the code is destined to break it (resulting in more work required of said constractor, so we have a dangerous incentive here). 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? 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). And, on your job: how many projects you worked on that have a comprehensive list of requirements? [0] https://twitter.com/Medtronic/status/1245777861774118913 https://twitter.com/Medtronic/status/1245777861774118913

milkytron 6y ago
> 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 get that he's trying to make the point that the software is complex with his statement. But how much does that really matter? Code can be really complex in a single line. And if the line count does matter, how are they counting the lines of code? Lines used in dependencies and third party libraries would probably make up a good amount of the total code, which may or may not have been written by engineers at Medtronic. Maybe this is a pointless comment, but these kind of metrics irk me and remind me of my days at a major bank when they measured productivity by number of commits.
lliamander 6y ago
> 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 6y ago
  That certainly helps. Thank God for the “blame”, er, “annotate” command.
- java-man 6y 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 6y 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.
StillBored 6y ago
I would add that "the job has failed". The next consultant who modifies the code is destined to break it (resulting in more work required of said constractor, so we have a dangerous incentive here). Cobol isn't really the problem here. Its more a problem of the system as a whole disagragating the data manipulation into different parts of the application, different batch jobs, whatever. OOP was intended to solve this problem (at least in a single application) by restricting the mutation and access of the data to a single class. Given a monolithic server model it worked. It is something that many of the modern programming languages completely fail at. Particularly the async oriented ones where its frequently possible to attach routines which mutate the state of an object from pretty much any point in the codebase. Combined with shared database access models/microservices/etc and systems get complex to the point where it takes real effort to logically map out all the individual parts which can read and modify a piece of data. So in a way the current model is very similar to the mainframe batch processing model, where a bunch of fairly small standalone "jobs" ran to perform limited functions. Instead today, we have event triggered micro-services. With all the same problems.
- Roboprog 6y ago
  I think it all comes down to having an understanding of your organization’s persistent data. You need to have a culture where people are allowed to become familiar with what is in their files and databases, and make sure they pass that knowledge on to others. Ideally in writing, but make sure it happens. Too many developers assign more meaning to this year’s code than is really justified.
  - java-man 6y ago
    You are right, but the "culture" has to be backed up with tools and processes. We can't rely on oral folklore to communicate the requirement and business decisions. People leave the company all the time, assumptions and requirements change. We need a git repo for requirements and business decisions, with pull requests and approvals, integrated with the main code repo.

milkytron 6y ago

> 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 get that he's trying to make the point that the software is complex with his statement. But how much does that really matter? Code can be really complex in a single line. And if the line count does matter, how are they counting the lines of code? Lines used in dependencies and third party libraries would probably make up a good amount of the total code, which may or may not have been written by engineers at Medtronic. Maybe this is a pointless comment, but these kind of metrics irk me and remind me of my days at a major bank when they measured productivity by number of commits.

lliamander 6y ago

> 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 6y ago
That certainly helps. Thank God for the “blame”, er, “annotate” command.
java-man 6y 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 6y 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.

StillBored 6y ago

I would add that "the job has failed". The next consultant who modifies the code is destined to break it (resulting in more work required of said constractor, so we have a dangerous incentive here). Cobol isn't really the problem here. Its more a problem of the system as a whole disagragating the data manipulation into different parts of the application, different batch jobs, whatever. OOP was intended to solve this problem (at least in a single application) by restricting the mutation and access of the data to a single class. Given a monolithic server model it worked. It is something that many of the modern programming languages completely fail at. Particularly the async oriented ones where its frequently possible to attach routines which mutate the state of an object from pretty much any point in the codebase. Combined with shared database access models/microservices/etc and systems get complex to the point where it takes real effort to logically map out all the individual parts which can read and modify a piece of data. So in a way the current model is very similar to the mainframe batch processing model, where a bunch of fairly small standalone "jobs" ran to perform limited functions. Instead today, we have event triggered micro-services. With all the same problems.

Roboprog 6y ago
I think it all comes down to having an understanding of your organization’s persistent data. You need to have a culture where people are allowed to become familiar with what is in their files and databases, and make sure they pass that knowledge on to others. Ideally in writing, but make sure it happens. Too many developers assign more meaning to this year’s code than is really justified.
- java-man 6y ago
  You are right, but the "culture" has to be backed up with tools and processes. We can't rely on oral folklore to communicate the requirement and business decisions. People leave the company all the time, assumptions and requirements change. We need a git repo for requirements and business decisions, with pull requests and approvals, integrated with the main code repo.