Live data from Hacker News

You are never taught how to build quality software

florianbellmann.com

281–290 of 500 posts

Re: You are never taught how to build quality software

#281
post #245

Earlier quoted context omitted.

> One is that we don't understand the fundamentals of software as well as the underpinnings of other engineering disciplines. That sounds like an awfully bold claim. I have the feeling we understand software a lot better than we understand mechanical engineering (and by extension material sciences) or fluid dynamics. By a big margin. I worked with finite element software and with CFD solvers, you wouldn't believe how…

> That sounds like an awfully bold claim. To the contrary, it's nearly canonical. Most of the problems pointed out in the 70s (mythical man month) have still not been resolved, 50 years later. >you wouldn't believe how hard it Oh, I'd believe it (I've designed and built similar things, and had colleagues in CFD). But you are definitely cherry picking here. The problem with CFD is we don't understand the fluid dynamic…

The article is about delivering a complete, working project "on time". I have a neighbor whose home is being renovated and it is already 2x the time the contractor originally quoted.

Of course it is easier for a developer to walk away from something incomplete than an architect and the contractors involved in a physical project, but still, I hardly think that there is really much difference in terms of timelines.

Re: You are never taught how to build quality software

#282
post #194

This has been previously handled in the excellent book "The Problem with Software - Why Smart Engineers Write Bad Code" by Adam Barr ( https://mitpress.mit.edu/9780262038515/the-problem-with-soft... )

I literally can't figure out how to buy the book from that site. I clicked ebook, then amazon, and the link is dead. You should probably just share a working link.

The Problem with Software - Why Smart Engineers Write Bad Code by Adam Barr

https://www.amazon.com/dp/026203851X

Re: You are never taught how to build quality software

#283

Earlier quoted context omitted.

> If you believe you can ship bug free code, it's time to switch careers. Unfortunately, you are correct. Shipping in time and bug free are inversely proportional, and in a world were usually it's hard to argue with PMs for more time to have better testing, or paying tech debt... it's just a reality

An infinite amount of time would not necessarily yield zero bugs. But more importantly, once you've fixed the "show-stopping bugs," putting the software in front of customers is probably the best next step, as even if it's bug-free, that doesn't mean it solves the problem well.

> An infinite amount of time would not necessarily yield zero bugs.

Never said that, just that quick turnaround for deliveries will usually mean more bugs, and having some extra time usually means less bugs

Re: You are never taught how to build quality software

#284
post #117

We do teach these things, they are just not core CS topics, but rather in other areas, relegated to electives like a software engineering course. At CMU we have entire Master's program for software engineering and an entire PhD program (in my department). We teach exactly the kinds of things the blog post is about, and more. Software Engineering is a whole field, a whole discipline. I get that this is a blog post and…

I chose software engineering. 3 years into the program the head of the department made a speech at an event to the effect of "Software hasn't changed in the last 10 years". It instantly devalued the entire program for me.

I have news for you... He's not wrong. The porcelain is different, but the same methodologies and processes are in place. The biggest change recently is distributed (mostly ignored) version control, that's 20 years old, and continuous integration/development (probably also around 20 years old, but only catching on in the last 10-15 years).

Computer science has changed more, there are lots of developments in the last 5-10 years.

Re: You are never taught how to build quality software

#285
post #42

Earlier quoted context omitted.

> If you believe you can ship bug free code, it's time to switch careers. Unfortunately, you are correct. Shipping in time and bug free are inversely proportional, and in a world were usually it's hard to argue with PMs for more time to have better testing, or paying tech debt... it's just a reality

That's only true up to a point. There are some quality assurance and control activities that are essentially "free" in that they actually allow for shipping faster by preventing rework. But that requires a high level of team maturity and process discipline, so some teams are simply incapable of doing it. And even in ideal circumstances it's impossible to ship defect free software (plus the endless discussions over wh…

There are tools that help, but you still need time to integrate those tools, learn how to use them, etc. If you are doing unit and integration tests, you need time to not only write those, but also actually plan your tests, and learn how to write tests. Which... needs time

Re: You are never taught how to build quality software

#286
I work in QA automation and also develop my own projects. There is more to quality assurance than QA. When you spend days creating something and then throw it away to make it better, that IS quality assurance! That deleted code, that deleted architecture, that deleted design is the cost of quality. A totally unappreciated aspect of QA.

Re: You are never taught how to build quality software

#287
post #245

Earlier quoted context omitted.

> That sounds like an awfully bold claim. To the contrary, it's nearly canonical. Most of the problems pointed out in the 70s (mythical man month) have still not been resolved, 50 years later. >you wouldn't believe how hard it Oh, I'd believe it (I've designed and built similar things, and had colleagues in CFD). But you are definitely cherry picking here. The problem with CFD is we don't understand the fluid dynamic…

The article is about delivering a complete, working project "on time". I have a neighbor whose home is being renovated and it is already 2x the time the contractor originally quoted. Of course it is easier for a developer to walk away from something incomplete than an architect and the contractors involved in a physical project, but still, I hardly think that there is really much difference in terms of timelines.

FWIW in my experience delays in e.g. home renos (or for that matter larger scale projects) are mostly for reasons unrelated to the engineering. In software projects, it's probably the #1 reason (i.e. we didn't know how to do it when we started).

Software is still absolutely king for number of large scale projects that just never ship, or ship but never work.

Re: You are never taught how to build quality software

#288

Earlier quoted context omitted.

> If you believe you can ship bug free code, it's time to switch careers. Unfortunately, you are correct. Shipping in time and bug free are inversely proportional, and in a world were usually it's hard to argue with PMs for more time to have better testing, or paying tech debt... it's just a reality

Like the age old builder trope. "Cheap. Fast. Good. Pick two."

That's the optimistic viewpoint.

The pessimistic viewpoint is that you get to pick up to one.

Re: You are never taught how to build quality software

#289
post #152

Earlier quoted context omitted.

Do SE classes teach debugging skills? I hope they do. So many times I have seen people try random things rather than follow a systematic approach.

I worked with programmers around my junior year and some of them were in classes I was in. I thought they were all playing one-upsmanship when I heard how little time they were spending on homework. 90 minutes, sometimes an hour. I was a lot faster than my roommate, and after I turned in my homework I’d help him debug (not solve) his. Then I was helping other people. They really did not get debugging. Definitely felt…

This is why internships and real world experience is so important. A course is 3 in class hours a week over 12-14 weeks typically. After homework and assignments it is ultimately maybe 40-80 hours of content.

Which means you learn more in one month of being on a normal, 40 hour workweek job than you have in an entire semester of one course.

Re: You are never taught how to build quality software

#290
post #267

Earlier quoted context omitted.

There's a massive gap between taught at CMU and taught at most universities. And even if it is taught, it's usually outdated or focused on very literal stuff like how to write web applications. I'd have killed for a class that actually focuses on implementation, on teamwork, on building complicated systems.

That was a dedicated software engineering course I took at university. Teams of 5. Had to put the soft eng theory into practice. And if’s not CMU.

Do they funnel soon to be grads into stressful zoom calls where product managers handwave an entire legacy stack still somehow running on coldfusion and want a rebrand with 'AI' starting Jan 1??
Post reply on HN