Compare&contrast my Julia development philosophy to agile development/etc

Offtopic
1

This philosophy is not specific to Julia, but favors Julia due to its high-level nature, ease of generic, etc… I want to compare them to popular development philosophies. Thanks.

  1. Code is either an end-user application or (part of) a library.
    This separates code into two neat categories.

  2. Each functionality should be owned by one person (can be advised and ownership/maintainer can change, and the functionality can be forked into several variants, but each should be maintained by ONLY ONE PERSON.
    This also means the project manager needs to assemble the final application together.

While this sounds like a strange philosophy, it is based on a simple observation. Imagine you ask someone to print hello world. “Please print hello world for me.” Well, you could’ve more simply done it yourself

println(“Hello world”)

Of course, this was a “simple” function, but inside, it actually had to call lots of IO and so on. This illustrates the principle well, with the right abstraction/tool, you could more easily do whatever you want to yourself. The help others provide is simply providing a layer of abstraction. If you specify what you want to build specific enough, you could have written your code. Therefore, you can communicate through programming abstraction lots of programmers spent decades perfecting?

  1. Library API should be documented.

So they’re usable. The response to “please print hello world for me” could be like “print(x) takes x that can be converted to string and prints it out to studio”

  1. A library should be as generic as plausible

So they can be re-used more, and more reasoning below.

  1. Respond to uncertain requirement and defer knowing requirement with generic code.

Maybe your customer changes the specifications all the time. Unlike other philosophies that might do some quick prototyping and so on, this philosophy says that ideally, the code should be generic enough that even crazy-sounding specification change is only a few line of code change in the final application code.

  1. Shorten/simplify end-user application code.

Move functionalities to generic library when possible. This helps code re-use. End application can’t be re-used.

So, in summary, this practice divides the code into documented, generic libraries and short end-user applications that takes only 1 person to produce. Complex projects can be made into short code that divides task into functionalities that themselves can be subdivided.

What do you think about this approach? Compare this to scrum methodology or whatever.

3 Likes
2

Eventually it works like that, but I find that a lot of code moves organically from “scripts” (which can live in a package in Julia, for easier development) to “libraries”, and then libraries can be split and merged as required.

Theory can be neat, practice isn’t.

That’s apples and oranges. What you describe is a goal of how code should be organized, “scrum” (with sprints, daily stand up meetings) is a process about how to get to your goal.

Unless you are part of a large organization, I would not worry about project management buzzwordology. If you are, then it will be provided for you and you won’t be able to escape it anyway.

2 Likes