You have 128 seconds to name a software development methodology that creates the least amount of bugs

You have 128 seconds to name a software development methodology that creates the least amount of bugs.

Attached: bugs.png (400x507, 454K)

Other urls found in this thread:

amazon.com/dp/0132350882/ref=emc_b_5_i
github.com/kelseyhightower/nocode
twitter.com/SFWRedditGifs

procrastination

You have 30 seconds to neck yourself.

Small maintainable code snippets

Unix way.

This.

this

Purist TDD.

Monolithic will always outperform modular.

Encapsulation/black box abstraction
t. Still learning

Not at scale.

Attached: wrong.jpg (600x480, 38K)

The one about not using pajeet devs

just know what you're doing alternatively have done it before lmao

or try to be a little thing i like to call 'intelligent'

>muh scale

>Monolithic will always outperform modular.
thank god we are in 21st century and performance is afterfought

Every Windows application is a proof of your claim.

Copy/pasting from other projects or Github into Visual C#. If it's from another language, fix syntax errors (that's what IDE grammar is for).

t. uses 17 web frameworks, 100 libraries and 3 build systems piled on top of one another to write a simple hello world

if your project is at any point less than 10mb, you're doing something wrong

Holy cow
cat >hello.c

any methodology but you reduce the team maximum of two

the result is always 0

Why? How? The man page of printf state that it returns a negative value in case of error.

the instruction is if it fails, it returns 1, but it doesn't stop and returns 0.

your better putting a else { } statement instead

>it returns 1, but it doesn't stop and returns 0.
What? Do you know C?

Do you have any idea what scale means or are you just regurgitating something you heard on reddit

If you are building anything involving more than 5 business entities you need an architecture/namespace structure that makes sense in that context, and simultaneously provides other organizational contexts (vendor services, for instance). There is no single name for this. I'd check out this book:
>amazon.com/dp/0132350882/ref=emc_b_5_i

In terms of development process across time, you need to be able to build+deploy your code in 1 click or less. Continuous Integration is the buzzword here, but just grab yourself a jenkins CI instance, point it at github and develop whatever shell/powershell script you need to build and deploy your solution. This part of the process takes time, but once you have a software build+delivery pipeline, it makes iterating on your codebase infinitely faster.

The above is the only way to manage bugs realistically. TDD is a fucking meme. You have to iterate and test ad infinitum to eliminate bugs in practical use cases. The faster you can suck down a bug report, punch in code (which is enhanced by having a clean code architecture), have it built+deployed, the faster you can check to see if its fixed. You will have bugs. You cannot code against bugs. They will find you and fuck your day up. The best you can do is be ready with a rape-fast process to iterate around them.

Attached: Screen Shot 2018-06-23 at 9.06.58 AM.png (596x778, 492K)

Waterfall

Attached: tumblr_nxi6ej0oFQ1qb5go1o9_1280.jpg (660x660, 43K)

>You cannot code against bugs.
Wrong you pajeet. Also TDD is at least going to the right direction, but writing tests first leads to you making tests for things that might never even be used for production. You write 'testable' code and then tests that come after are natural.

This guys the reason we have so many Java monoliths shitting up ecosystems everywhere.

I never advocated against writing tests. I absolutely agree with adding tests that you identify naturally through the development process, or through bug reports. This is how a codebase eventually becomes seasoned with an excellent testing framework. That said, I think that writing tests before writing the code-under-test is 100% fucking retarded.

Keep it simple, stupid

>Clean Code
Martin Fowler's Refactoring is just so much better when it comes to the subject. Uncle Bob's book commits all of its coding sins in literature form.

Yeah I cant really advocate one book over the other. All I can do is advocate for the software development process in general. You go around the block enough times and you start to see patterns. We got to the point where we can spin up a new boilerplate .NET AspNetCore API+SPA website in github, have a server for it to run on (including DNS), and a build job to build+deploy it, all within 5 minutes or so. It is absolutely insane what kind of efficiency gains you can find when you standardize your software engineering process into a bucket of legos you just move around as you see fit. Copy pasta is a very very powerful thing.

Lone Wolf.

Does formal specification and verification count?

not doing your open test exam for you jamal
should have studied

All good stuff. Writing good code and setting up a deployment pipeline are kind of two different things though. Having one touch build pipeline should be part of any major project.

Not writing any in the first place.

This.

Also, UML diagrams are pretty good. They never have bugs.

Test-driven

t. automobile industry pro

stop hiring people with no degrees

Derivations from formal specifications (for example Hoare logic).

MISRA C

privsep

What does uncle Bob do wrong
Curious

Hoare logic? No way can you do that on code base that's larger than 100 lines

Contrived, drawn out examples, irrelevant code changes, and lack of focus in chapters for the most part. In a lot of cases it takes you on an adventure when it should be explaining its technique and thought process. You can work your way through Uncle Bob's book, or you can just flip open Refactoring and get everything his book is trying to teach without the hassle.

Domain Driven Design, Behavior Driven Development

Keep It Simple

Abstraction. Clear code > Max optimization with complexity

TDD

>That said, I think that writing tests before writing the code-under-test is 100% fucking retarded.

In most cases, yes. But for generic data structures it makes a lot of sense since the contract is already known.

breakpoints.

LMAO

program synthesis from formal specification

github.com/kelseyhightower/nocode

A combination of Test Driven Development, Unix Philosophy, and Git Flow.

Attached: game-blouses-1.jpg (550x417, 54K)

Formal methods, aka do whatever the people writing control software for planes do.

Not writing code

It sucks that I wasted 2 years of my college life learning the RUP method. Don't listen to college counselors who say programming is going to be outsourced and go into project management.

I have a tumor of an sql query, I compartmentalized the customizeable parts of it into strings above said query for easy edits so you don't have to worry about the rest of the block. Looks beautiful IMO

>software development
programming

don't be fooled, there's a clear answer to this.
Haskell, a functional paradigm programming language.

SCRUM


Here, I said it.

>make it small
>make it modular
>make it portable
>do one thing and do it well
>muh Unix Philosophy
>actually test your shit thoroughly

Attached: 8e7.jpg (528x404, 20K)

Literally the only one that counts. We live in a world where highly important security software and fucking CPUs have not just bugs but outright vulnerabilities because code monkeys think writing down some piece of code that kinda seems to work counts as software development. If you don't take the Dijkstra pill, you're putting people in danger.

agile, but everyone actually follows the rules

a single dev with no interference from others and a long release timeline