Why get out of the hamster wheel?
You are never taught how to build quality software
231–240 of 500 posts
Re: You are never taught how to build quality software
#232I completely understand university teaching algorithms over real dev stuff.
Algorithms are hard, and take serious work, they're basically math. University seems like the idea place to learn A* search or quicksort, I can't imagine figuring that out without a lot of effort and time spent just focusing on that.
What I don't understand is why programmers themselves focus on algorithms over stuff like "Vague heuristics to guess if this JS framework you tear your hair out in a month".
That kind of this isn't really hard and doesn't require any heavy discipline and focus, it's just something you pick up when you've tried a few different systems and notice stuff like "Oh look, that linter caught this bug for me" and "Hey look, there's not much autoformat support for Mako, maybe I'll just use Jinja2 like everyone else".
Instead they tell us to do stuff like code katas and endlessly polish our coding and algorithm skills rather than practice working on big stuff and managing complexity.
Maybe it's because algorithms are the hard part, and being really good at that is needed to work on the real cutting edge stuff.
Re: You are never taught how to build quality software
#233There is a corollary. You need to learn how to build quality software. You also need to know what level of quality vs completeness tradeoff you need to make. Imagine I have a deadline of Jan 15th to demo features x, y, and z to senior leadership (who then will make funding decisions that could impact my project), and I get to Jan 15th with x, y, and not z - or worse, none of them working fully. But the code quality i…
I think that "quality software" is not well defined, so until it's well defined, we're not talking about the same thing.
Re: You are never taught how to build quality software
#234Earlier quoted context omitted.
If it works within specs it is bug free. It doesn’t matter how it is made if it works within specs, which is one of the real unfortunate truths of software. The other is working out the correct specification is far harder than coding is. For example it is trivial to write a bug free program that multiplies an integer between 3 and 45 by two.
> If it works within specs it is bug free. No, it's functional. If it has bugs, it's not bug-free. By definition.
Not to get too meta here but… what is your definition of a bug? One plausible definition is “system deviates from its specification”.
Re: You are never taught how to build quality software
#235Almost no university teaches software testing in a competent way. For some years, Cem Kaner and I (he, a professor at Florida Tech; me, a proud high school dropout) ran a small annual conference called the Workshop on Teaching Software Testing. We specifically invited Computer Science professors to come and grapple with the problem. Thus, I personally witnessed and engaged with the sorry state of practice with teaching people about testing.
Cem developed a great testing class for Florida Tech, later commercialized under the name BBST, that drew in contributions from prominent industry voices. Otherwise, I don't know of any other University that has put the effort in. An exception may be what Tanja Vos is doing at Open University.
The problem I have with CMU is that they are the source of the Capability Maturity Model, which is simply incompetent work, justified by no science whatsoever, which tries to apply Taylorist management theory to software engineering. It never caught on despite all the marketing they've done-- it's only popular in military circles. I shudder to think what they are telling students about testing.
You can disagree with me, of course-- but in doing so you have to admit there is at least a schism in the industry among various schools of thought about what testing is and should be. My part of the field considers testing to belong to social science, not computer science.
Re: You are never taught how to build quality software
#236Earlier quoted context omitted.
You might be correct today but that’s a pretty sad state of affairs, don’t you think we can do better? Most other engineering domains can deliver projects without bugs, with various definitions of “bug” of course
I'm not sure about that. Which engineering domain do you have in mind? Maybe show-stopping bugs are somewhat unique to software engineering, but all somewhat-complex products are flawed to some extent imho. It might be an unergonomic handle on a frying pan, furniture that visibly warps under the slightest load (looking at ikea shelfing) or the lettering coming off the frequently used buttons on a coffee machine.
There are many examples of catastrophic bugs in real life.
New bridges collapses, dams overflow s, planes crashes, vaccines kills, food kills, leaning towers and skyscrapers, capsized ships - catastrophic flaws are everywhere.
Re: You are never taught how to build quality software
#237Earlier quoted context omitted.
What would it mean to be bug free then? To quote a former marketing guy “it should work out what the user intends to do and do it”?
To have no bugs, which is extremely unlikely for a program of any real complexity. Having bugs, and being functional, are fairly self-explanatory and independent of each other. No need to try to conflate them. Not sure what your quote is supposed to mean. That's a textbook example of someone who doesn't understand software at all making laughable requests of their engineers.
To be bug free we must be able to define what a bug is. So, what is a bug?
The reason for that quote is from what you have said a bug would be anything you didn't expect, even if it is consistent or not with the specification as that merely affects if we classify it as functional or not (a classification I profoundly disagree with, obviously). It is simply a negative rephrasing of what the marketing guy said and laughable in the same way.
Re: You are never taught how to build quality software
#238Like with all things quality is proven through practice and measures, which means quality can only be guessed at before a product is built.
Like in all things here is how you do it:
1. Build a first version that works and accomplishes all initial business requirements.
2. Build test automation or inspection criteria.
3. Reflect upon what you built and watch how it’s actually used in production.
4. Measure it. Measure performance. Count user steps. Count development steps. Determine real cost of ownership.
5. Take stuff out without breaking business requirements.
6. Repeat steps 2-6.
That is how you build quality whether it’s software, manufacturing, labor, management, whatever.
In my own software I devised a new model to solve for this that I call Single Source of Truth. It’s like DRY but hyper aggressive and based upon empathy instead of micro-artifacts.
Re: You are never taught how to build quality software
#2391. The premise that college teaches you how to build software in industry is a pretty wild claim. 2. Is this article from the 90s where we ship software on CDs or floppy disks? In today's world where the concept of a "release" is often blurred by continuous delivery pipelines (and this is considered a good practice), having a quality insurance department manually assuring that no bugs are in that release seems downri…
And then you remember stories like that about Boeing. How their 737 Max has been tested by cheap contractor from India.
There are tons of software without continuous delivery.
Re: You are never taught how to build quality software
#240Maybe a spicy take (FWIW I'm also self-taught) Software engineering quality isn't something you teach, it's something you learn.
I think developing high quality software is more art than engineering.
The most useful pieces of code typically have to deal with some of the most ridiculous constraints. Determining a way to integrate these such that the UX doesn't suffer is the real talent.
The only pedagogical model that makes sense for me anymore is the apprenticeship. You can definitely learn it on your own, but it's a hell of a lot faster to observe someone with 20k+ hours XP and skip some of the initial lava pits. Perhaps some of those lessons are important, but learning and knowledge are not linear things.