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

421–430 of 500 posts

Re: You are never taught how to build quality software

#421

Post by rvdginste »

__loam wrote: post #344
petsfed wrote: post #215

Earlier quoted context omitted.

What would be better? Change tools every 3-5 years like the industry does, so by the time any given instructor actually has a grasp on a particular tool or paradigm, its already obsolete (or at least fallen out of fashion) too? I'm no fan of UML, but the exercise is to teach students how to plan, how to express that plan, and how to reason about other people's plans. The students will certainly draw a lot of flow dia…

I haven't seen a UML diagram once in 7 years of working. The approach presented in the book "a philosophy of Software Design" is much better than the outdated bullshit from the 90s.

I never got the hate against UML. To me, UML is just a language to communicate about several aspects of a technical design, and to visualize a technical design to make it easier to reason about it.

I did not read the book "a philosophy of software design", but I just scanned the table of contents, and it is not clear to me how "a philosophy of software design" contradicts with using UML.

Are you telling me that in those 7 years of working, you never once used a class diagram? Or a database diagram? Or an activity diagram, deployment diagram, sequence diagram, state diagram?

I find that hard to believe... how do you explain your design to other people in the team? Or do you mean that you do make that kind of diagrams, but just use your own conventions instead of following the UML standard?

Personally, I often use UML diagrams when I am working on a technical design and I use those diagrams to discuss the design with the team. On almost every project I create a class diagram for all entities in the system. I rarely make a database diagram because that often is a direct translation of the class diagram. For some of the more complex flows in the system, I create an activity diagram. For stuff that goes through state transitions, I create state diagrams. In my case, this really helps me to reason about the design and improve the design. And all those diagrams are also very useful to explain the whole software system to people who are new on the project.

That does not mean that my diagrams are always strictly UML-compliant or that I make a diagram for every little piece in the software system. The goal is not to have UML-compliant diagrams, but to efficiently communicate the technical design to other people, and UML is nice for this because it is a standard.

Re: You are never taught how to build quality software

#422

Post by valand »

xmprt wrote: post #227
MaxBarraclough wrote: post #206

Earlier quoted context omitted.

A formal spec isn't just ordinary source-code by another name, it's at a quite different level of abstraction, and (hopefully) it will be proven that its invariants always hold. (This is a separate step from proving that the model corresponds to the ultimate deliverable of the formal development process, be that source-code or binary.) Bugs in the formal spec aren't impossible, but use of formal methods doesn't preve…

I think the reason that formal proofs haven't really caught on is because it's just adding more complexity and stuff to maintain. The list of things that need to be maintained just keeps growing: code, tests, deployment tooling, configs, environments, etc. And now add a formal proof onto that. If the user changes their requirements then the proof needs to change. A lot of code changes will probably necessitate a proo…

You mix up development problem with computational problem.

If you can't use formal proof just because the user can't be arsed to wait where it is supposed to be necessary, then the software project conception is simply not well designed.

Re: You are never taught how to build quality software

#423

Post by jaybrendansmith »

hinkley wrote: post #165
titzer wrote: 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…

If my friends hadn’t had such vividly bad experiences with the compiler class, I might not have taken the distributed computing class that was one of the other options to fulfill that category. It’s not the most defining class of my undergrad years, but it was pretty damned close. The fact that most people designing systems don’t know this material inspires a mix of anger and existential dread.

After seeing the same mistakes made over and over again I can't help but agree. This is how one builds enterprise software now, and it is poorly understood by most developers, although that is starting to change. If I were designing a college curriculum, required courses would include all of the normal CS stuff but also software engineering, distributed computing, design patterns, web application fundamentals, compiler design, databases, DevOps/Cloud, testing fundamentals, UX design, security basics, data science, IT project/process management, essentials of SOA, product mgt and requirements. Of course, it's been so long since I went to college, none of these things existed back in the day, so perhaps modern curriculum has all of these now!

Re: You are never taught how to build quality software

#424

Post by rvdginste »

mrweasel wrote: post #414
crysin wrote: post #157

Earlier quoted context omitted.

Got my MS in SE at DePaul University in Chicago. Wrote more UMLs for those classes than I’ve done in 10 years of actual software development.

While I'm not suggesting that UML is necessarily the solution, I hope it's not, but the observation that so few developers touch anything that just looks like UML is a good indication that a lot of software is in fact NOT designed, it's just sort of hobbled together from a few sketches on a whiteboard.

I hope that people say they hate UML and then just make UML (class, database, activity, ..) diagrams according to their own conventions, but I am afraid you are right and that a lot of software is just "hobbled together"...

Re: You are never taught how to build quality software

#425

Post by steveBK123 »

denton-scratch wrote: post #397
sdiupIGPWEfh wrote: post #359

Earlier quoted context omitted.

> strict cheating policies that essentially made any group work verboten If I had to guess, some polytechnic school or another? With some classes even forbidding discussing work with other students, where each assignment required a signed (digitally or otherwise) affidavit listing everyone you consulted, acknowledging that if you actually listed anyone, you were admitting to violating the academic honesty policies an…

I had students that copied one-another's work; in fact I had few students that didn't copy. It made it impossible to mark their projects correctly, so I asked my more-experienced colleagues. The best advice I got was to explain the difference between collaboration (strongly encouraged) and plagiarism (re-take the course if you're lucky). Forbidding collaboration is a disastrous policy, so an instructor shouldn't have…

My school auto-graded everything (file drop your code to a server by midnight & get a score back). I don't recall a single instance of TA/professor written or verbal feedback on code.

Re: You are never taught how to build quality software

#426

Post by steveBK123 »

virgilp wrote: post #373
sdiupIGPWEfh wrote: post #359

Earlier quoted context omitted.

> strict cheating policies that essentially made any group work verboten If I had to guess, some polytechnic school or another? With some classes even forbidding discussing work with other students, where each assignment required a signed (digitally or otherwise) affidavit listing everyone you consulted, acknowledging that if you actually listed anyone, you were admitting to violating the academic honesty policies an…

I taught a course "in a previous life" and while I wasn't anything close to as strict as you say here, I can tell you the flip side: students would copy, modify superficially (some, less superficially) and then claim "it's my work, we just talked, that's why the similarities!" (with some even having the nerve to say, "it's not copied, look, plagiarism detection software says similarity is less than x%!) Perhaps I was…

Sure, but given how we all work in the real world.. there should be courses that are explicitly "group project" based.

Re: You are never taught how to build quality software

#428

Post by marcosdumay »

mdaniel wrote: post #340
bluGill wrote: post #220

Earlier quoted context omitted.

I wish someone would create that 500 line checklist. I've seem attempts, but they tend to be either not actionable (is the software high quality - meaningless), or of metrics that are just gamed (is test code coverage > 80%?)

> or of metrics that are just gamed (is test code coverage > 80%?) The rebuttal to your implied Goodhart's Law https://en.wikipedia.org/wiki/Goodhart%27s_law > that was offered by my manager was "tension metrics" https://en.wikiversity.org/wiki/IT_Service_Management/Contin... > If I understand his theory correctly, in your case there would be a competing metric to the "test coverage" one that said for any changeset,…

Hum, now you are proposing a process checklist that can't ever be completely checked out, by design.

The entire thing is terrible from principle. You won't find a good example, because that's not how you use a process checklist.

Re: You are never taught how to build quality software

#429

Post by Solvency »

anacrolix wrote: post #284
fudged71 wrote: post #280

Earlier quoted context omitted.

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…

So you're not a JS developer. Got it.

Re: You are never taught how to build quality software

#430

Post by randomdata »

marcosdumay wrote: post #9
randomdata wrote: post #2

Is there any human activity where quality is an attribute successfully taught? In my experience, being able to produce something of quality is gained only through practice, practice, practice.

> Is there any human activity where quality is an attribute successfully taught? Every industrial practice. On the other hand, the title just means that programming is not an industrial practice. What should be obvious to anybody that looked, but some people insist on not seeing it.

What industrial practice isn't guided by carefully designed machines that remove the human variability?
Post reply on HN