Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You are never taught how to build quality software

florianbellmann.com

Post reply on HN
Print view View original

361–370 of 500 posts

Re: You are never taught how to build quality software

#361

Post by valenterry »

ch4s3 wrote: post #256
t43562 wrote: post #224

The reason I find it easier to work with people who have a degree in Computer Science is that I don't have to convince them of the need for good algorithms and not to try to implement parsers or cryptography by hand. When it comes to software engineering I feel there is no qualification where you can feel that the gross naivety about quality and working in teams (and with other teams) has been similarly ironed out. I…

Hum, interesting perspective. I did 95% of a masters in CS before leaving to do a startup and while I can see the value of parser generators, there are a LOT of times when it is appropriate, useful, and more performant to write your own simple parser. It's often in my opinion the right thing to to first for simple cases. Clearly you should test it and consider functional requirements, but a stringy protocol with clea…

I've never had it once in my career where using a parser generator wasn't better. Given that it's an in-language parser generator and not some meta-language monstrum like ANTLR.

Maybe when writing your own programming language, own complicated data format or low communication protocoll while requiring extreme performance. But that seems to be super rare, at least in my area of profession.

Re: You are never taught how to build quality software

#362

Post by pushedx »

I went to a University with required Co-Op experience in industry. There was a great feedback cycle of students coming back to classes and writing tests and design documents for assignments that didn't even require them. Reading articles like this make me really grateful for that.

Re: You are never taught how to build quality software

#363

Post by accurrent »

heelix wrote: post #276
hardwaregeek wrote: post #160

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.

I've wished that students would be required to hand their semester long project to the person next to them each week.

The university I went to had this. We had to maintain an application that was built by our seniors and then hand that off to the next batch.

Re: You are never taught how to build quality software

#365

Post by Mtinie »

AlphaWeaver wrote: post #350
foobiekr wrote: post #325

Earlier quoted context omitted.

For years a friend tried to get his department (where he worked as a lecturer) to add a software engineering course where the basic syllabus was to (1) receive a TOI from the last semester and the code base, (2) implement some new features in the code base, (3) deploy and operate the code for awhile, and (4) produce a TOI for the next semester. The code base was for a simple service that basically provided virus/malw…

In my university, (US, state school,) we had a software engineering course exactly like this. It was great in theory, but in practice, the experience was rushed, the codebase was poor quality, (layers upon layers of nothing features with varying code quality,) and the background knowledge was completely ignored. The application we had to work on was a Tomcat Java Web application with an Angular frontend, when neither…

Am I understanding correctly that your concern was that the course is too close to reality to be useful?

Re: You are never taught how to build quality software

#366

Post by bottled_poe »

benreesman wrote: post #312
ttymck wrote: post #310

Earlier quoted context omitted.

I think the prevailing problem is that quality software often doesn't outperform shit software in terms of revenue, right?

CloudFlare and TailScale and that crowd don’t seem to be chancing it?

They are outliers. Most startups focus on feature velocity and sales first, quality is an afterthought, regardless of what they might say. Also, if your project is open source, quality has a lot more weight towards uptake.

Re: You are never taught how to build quality software

#367

Post by rocqua »

KeplerBoy wrote: post #18

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

I think with formal analysis, whole bug classes can be eliminated. Add to that a rigorous programming style, and 'bug-free' code is within reach. There will remain bugss that make it through, but they will be rare, and will need a chain of mistakes.

Currently ways of coding to this kind of standard exist. But they are stupid. It involves things like no dynamic memory allocation, only fixed length for-loops, and other very strict rules. These are used in aerospace, where bugs are rather costly and rare.

Re: You are never taught how to build quality software

#368

Post by rocqua »

datadeft wrote: post #90
KeplerBoy wrote: post #18

> It will be necessary to deliver software without bugs in time. Seems like a pretty bad premise to start an article on quality software. If you believe you can ship bug free code, it's time to switch careers.

Spicy take on engineering. Why do we accept this for software when do not accept the same in other engineering domains?

I mean, bridges collapse. That hasn't meant we gave up on engineering bridges. Point being, we have some risk tolerance, even for civil engineering.

Now we don't accept an engineer saying, "this bridge will probably collapse without warning", which we do accept with software. So there is a difference.

Re: You are never taught how to build quality software

#370

Post by rocqua »

Gud wrote: post #95
datadeft wrote: post #90

Earlier quoted context omitted.

Spicy take on engineering. Why do we accept this for software when do not accept the same in other engineering domains?

Trust me when I say this: even "other" engineering domains have to do patches. The difference is that software can be used before it is fully ready, and it makes sense to do so. No one can really use a 90% finished power plant, but software at 95% capacity is still usually "good enough"

Thanks for this insight! It has pretty strong explanatory power. It also explains why rushed development can stall. It explains 'move fast and break things'.

There's even an added factor of learning more about what is really needed by putting a 95% done product into use.

Heck, it explains (stretching it here) space-x's success with an iterative approach to rocket design.

Post reply on HN