Submitted via IRC for SoyCow4408
Software development is a complicated discipline, especially when you consider that it is performed by several people working together.
Comparing it to emergent systems is useful because it provides a perspective where we can think of software as something that evolves.
Being able to measure that evolution is then crucial if we want to be able to tell if the product we are building is holding up in terms of quality.
I also describe a tool named NDepend that serves exactly this purpose (and as far as I know has no competitors). It provides extensive metrics and allows for the creation of custom rules, all of this while supporting integration with a continuous integration workflow.
Source: https://www.blinkingcaret.com/2018/08/22/software-development-emergent-system-ndepend/
(Score: 5, Funny) by Snotnose on Monday August 27 2018, @02:26AM (1 child)
Too bad it's on the wrong site :(
I came. I saw. I forgot why I came.
(Score: 0) by Anonymous Coward on Monday August 27 2018, @07:03AM
Yeah, the article completely derails and the product doesn't even have anything to do with what the article starts out with.
And considering the actual real-life usefulness of metrics (at best a tool to figure out if you need to do code cleanup and where) suggesting a paid tool seems absurd.
Not because of the price (no idea about that) but because getting it purchased in a typical corporate environment will cost more time and effort than it will safe anyone.
(Score: 4, Interesting) by fyngyrz on Monday August 27 2018, @02:27AM
Not always, it isn't. There are some that do the whole thing, including documentation.
(Score: 1, Interesting) by Anonymous Coward on Monday August 27 2018, @02:36AM
But it don't make no sense.
(Score: 5, Touché) by The Mighty Buzzard on Monday August 27 2018, @02:50AM
People are not spherical cows. What works well for one group works well for one group; no implication can be had that it will work well for any other group. Find what works well for your group and use it, adapting as necessary.
My rights don't end where your fear begins.
(Score: 1, Funny) by Anonymous Coward on Monday August 27 2018, @06:47AM (1 child)
Assuming it's true, your product is either revolutionary or it has no competitors because nobody wants it. Look. I built an office chair that's guaranteed to make you fall over backwards. Nobody else makes them. It "has no competitors".
Alternatively, and more commonly, such statements are lies from marketing. Skimming over TFA that seems to be the case. It's code metrics. We've got that. We can already script it. We can do it in a lot of environments.
(Score: 2) by mth on Monday August 27 2018, @08:33AM
Yeah, nothing in the article sounds particularly new. Code metrics have been around for ages, several tools support custom rules (*), the idea of a compound score isn't new either. What I hadn't seen before is visualizing the score in treemaps: that looks useful but it's hardly a revolution.
(*) A feature that barely anyone uses, in my observation: I don't recall seeing custom rules used in projects I've come across. I've written my own custom rules using PMD and PyLint, but at a rate of less than one a year. I tend to only use it to find violations of project-specific coding rules that are easy to make and hard to spot, like a library class/function that must be used in a specific way. You're better off avoiding the need for such rules in the first place and programming languages have more constructs now that allow you to design APIs that are not so fragile.
(Score: 3, Insightful) by MichaelDavidCrawford on Monday August 27 2018, @09:49AM (1 child)
Ten times as much coder-years are spent debugging and maintaining code than implementing new features. Why isn't debugging more of a priority in our educations?
How many of you have read Robert Ward's "Debugging C"?
It's long out of date but can be had used for like a dollar. I made seven singing on the street [soggywizards.com] today, so you sorry lot have absolutely No Excuse.
That I read it in 1988 resulted in my getting hired by Apple in 1995 as a Senior Engineer in the role of Debug Meister. Whenever QA turned up a bug which they had no clue as to where it came from, or that was particularly difficult to reproduce or even if they did know where it came from, it was assigned to my team of five Debug Meisters. Phil Murphy maintained MacsBug. Perhaps you're heard of debuggers?
Everything I knew about debugging up until I read Ward's book was folklore passed down as oral tradition, sort of like Homer's Odyssey and Illiad were before the Greeks developed that screwy alphabet they're so heavily into.
Carnegie Mellon offers a Software Engineering major that is distinctly different from Computer Science. In Canada it's unlawful to call yourself a Software Engineer at all unless you have a Software Engineering degree as well as a Professional Engineering license of the sort that Civil Engineers always have. (The Ontario Association of Engineers love nothing more than to haul MCSE into court. They _always_ win.)
Help me out here, I'm begging you!
Yes I Have No Bananas. [gofundme.com]
(Score: 3, Informative) by fyngyrz on Monday August 27 2018, @04:16PM
This is only true for poorly built products. Solid design means both narrow and obvious debugging paths, and a lot less of it in the first place, as well as near-zero difficult maintenance (exceptions usually incurred by stupid alterations made by the OS vendor.) In such a design, almost all effort can be exerted in the direction of new features.
Having said that, the more you / your team uses Other People's Code (libraries, etc.), the more prone your product will be to problems. You can't avoid the OS for most designs (the few custom OS's out there notwithstanding), and again that's a problem that isn't remediable — Microsoft and Apple have both historically been far more concentrated on new products than they have on making the products they already have work as advertised. That's an albatross almost all of us have to carry, but technically, remediation isn't about bugfixing so much as it is writing workarounds for the OS vendor's irresponsibility. Oh, do I ever have stories to tell there. Debugging, however, is often called for. Cursing, too. :) Linux... Linux is a bit better here.
Unit testing (for just one example), which is an extremely powerful tool in this area, is a well understood mechanism and one that is easy to manage if you start with it on day one. Which you should do. If you're not using it, you're not even trying. If it wasn't part of your education, your education sucked. Before anyone says "but my degree was in 1970" or the like, your education should be ongoing, and unit testing is a well-established technology that you should have wrapped your head around long ago... education does not (okay, should not) stop with college. Furthermore, you are responsible for seeing to it that your education covers all the ground required. Degree or no.
Well, not knowing when you read it, and considering that it came out in 1989, soon afterwards, at the very least, the Internet became available and shortly after that there was considerably more information on debugging techniques available to everyone who had a network connection. At this point in time, debugging tools, techniques, tips and tricks are there for the taking, so this doesn't seem particularly relevant.
Sigh. This is exactly the wrong path to take. A degree does not an engineer make. It means you sat in classes and managed to conform to the requirements of the degree well enough to graduate. It does not mean you are any good at all at engineering. I can point to many hardware and software designs that have obvious, stupid problems from companies like Adobe and Microsoft and Apple that came from degreed hardware and/or software engineers. I have worked with many college graduates that were outright incompetent when it came to actually writing decent code, and a few who were just as bad at hardware. While a basic knowledge base (which you certainly don't need a degree to get) is certainly important, nothing beats actual experience in the real world, and the more of it, the better.
The main issue here isn't that college makes one competent (because it doesn't — nor does it make one incompetent) but that it provides a touchstone for companies to claim (inaccurately) that they tried to ensure that their employees were competent. This is done as a shield against lawyers and courts, who don't know any better than to think that a degree or test certification is actually meaningful in real world terms.
Education on debugging — and many other areas of quality design — is available from many sources. It's really an embarrassment of riches. That includes very reasonable summaries of the areas in which you need to be at least competent to execute a good design. Those summaries can be used to build a solid foundation at your own speed. Anyone with the smarts required to do software or hardware engineering should be able to self-educate quite well, and in terms of determining who to hire, someone with drive who can also demonstrate a series of solid designs would be a much smarter hire than Joe(line)-I-have-a-new-degree. If they can't self-educate, you really, really don't want them designing your goodies.
Finally:
...because college degrees tend to be extremely myopic in terms of what they cover, and also tend to be designed and taught by people who do not have real world experience; one of the reasons for the "ivory tower" epithet.
Yes... autodidact here. :)
(Score: 3, Insightful) by Thexalon on Monday August 27 2018, @01:38PM
It depends entirely on the application. A remarkable percentage of a wide variety of software development is simply a matter of shoving information from a UI into a database, and retrieving said information from a database and displaying it in a UI. With a little bit of basic arithmetic, statistical analysis and reporting maybe thrown in.
Except when it isn't, which is most of the time, because shops usually assign a ticket/story/task to individual programmers to get done, and while they can ask someone else for help ultimately they're mostly working on their own. And if you don't believe me that an individual and not a group is responsible for each change, watch what happens when those changes aren't occurring in accordance with the desired schedule.
Except that it isn't that at all, it's we hope intelligently designed, unless you're doing some sort of evolutionary algorithm kind of thing.
I think this is trying to say "Have a changelog".
There ain't no such thing as a software tool that can determine quality. Nor can such a software tool even theoretically exist: For example, all high-quality software should always be able to finish processing for an operation under all circumstances, and a generalized tool to determine if that is happening is something that cannot exist per Alan Turing's famous discovery decades ago.
At best, we can tell if the product we are building stands up to automated and manual testing by qualified QA folks.
Ah yes, the never-ending and completely pointless quest by non-technical managers everywhere for the magic "Do my programmers suck?" button.
a.k.a. "vendor lock-in", a.k.a. Some strange rules language that fits some designer's idea of what someone might possibly want to do but is less flexible than shell scripting.
It has a git repository, and a trigger on commit to run your automated testing suite. But this wording makes it buzzword-compliant.
Count me among those who isn't impressed by SoyCow4408's perfect expression of what comes out of the back of a cow.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.