Software development principles

Somehow, developing software is different from e.g., building a bridge. Let's explore that, and let's keep the example of building a bridge in mind:

• Software is probably the most complex artifact made my humans
• Software comes with bugs (building a bridge hardly does). Actionally, most of the time, programmers are fixing bugs, not actually programming
• Bug fixing should be integrated part of development: The longer bugs are not fixed, the harder it becomes to fix it [1]
• It's easier to write code, than to read it. One of the consequences of that is, that programmers tend to rewrite something from scratch, rather than improving existing code
• Programmers like to create new stuff. Not to improve existing stuff
• 80% of software is never going to be shipped - And this has some major consequences
• Writing software is not reducable, as how building a wall is reducable: You can measure who put how many bricks to build a wall. Such an approach doesn't work for software development.

Tastapod:

You shouldn’t start with the Spotify model. Spotify didn’t start with the Spotify model.

You shouldn’t start with Scrum. Scrum didn’t start with Scrum.

You should start by identifying what you want to improve, and introduce constraints that force the improvement.