Today it is hard to find some good ones. Because everyone had their opinions (and opinions are often like noses) how to develop software.
A collection of the good ones.
A try to collect the good stuff I found over past the years (since 2000)
I believe that good product could not be mass product.
Good vegetables you will find on a small vegetables market of farmers.
I believe in the lego principe And keep it simple. Most projects I saw with high level of complexity. That means you have no simple lego stones, but very complex one.
It seems that everyone one knows or heard this statement, but more me it seems nobody is doing it. This is a provocant statement that nobody doing that. But the real genuis seek for the simple. Why? Perhaps the wise people understand that you can not do anything higher when you start to complicated.
For instance as example. Every material is made out of atom. Atom are building stone of material. From Material you can build object. From Object you can build other objects.
https://en.wikipedia.org/wiki/KISS_principle
KISS, an acronym for "keep it simple, stupid" or "keep it stupid simple", is a design principle noted by the U.S. Navy in 1960.[1][2] The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided. The phrase has been associated with aircraft engineer Kelly Johnson.[3] The term "KISS principle" was in popular use by 1970.[4] Variations on the phrase include: "Keep it simple, silly", "keep it short and simple", "keep it simple and straightforward",[5] "keep it small and simple", or "keep it stupid simple".[6]
https://en.wikipedia.org/wiki/SOLID
In object-oriented computer programming, SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. It is not related to the GRASP software design principles. The principles are a subset of many principles promoted by American software engineer and instructor Robert C. Martin.[1][2][3] Though they apply to any object-oriented design, the SOLID principles can also form a core philosophy for methodologies such as agile development or adaptive software development.[3] The theory of SOLID principles was introduced by Martin in his 2000 paper Design Principles and Design Patterns,[2][4] although the SOLID acronym was introduced later by Michael Feathers.[5]
Design a software like building a house. First you need to know what to build. Make a plan and build if up layer by layer. Do not build the house from the roof. But always have the overview of the end result. Most do not know the end result, build something and change it and change it. If you change to often you get in a total mess which needs a lot of energy to keep it alive.
I believe that it much better not to be bride and get a hacker, but rather look at good apis and look how they made it then to create your own one's.
http://docs.autodesk.com/MAYAUL/2014/ENU/Maya-API-Documentation/
I believe that the examples in MSDN leads to bad programer pratice we all face of our colleagues. If a example writer writes an example of for instance loading something from the db and put into a dataview. He leads people to do this is production code. The purpose was to give a simple example. But in reality you should not do that. A good programer would do this in the event handler. But write a command and has different layers in the code. Would have an api. Would a MVP Pattern or some layers of abstractions. Whatever.
Fuchsia is a capability-based operating system currently being developed by Google. It first became known to the public when the project appeared on GitHub in August 2016 without any official announcement. In contrast to prior Google-developed operating systems such as Chrome OS and Android, which are based on Linux kernels, Fuchsia is based on a new microkernel called "Zircon", derived from "Little Kernel",[1][2] a small operating system intended for embedded systems, which was developed by Travis Geiselbrecht, a creator of the NewOS kernel used by Haiku OS.
LK (Little Kernel) is a tiny operating system suited for small embedded devices, bootloaders, and other environments where OS primitives like threads, mutexes, and timers are needed, but there’s a desire to keep things small and lightweight. On embedded ARM platforms the core of LK is typically 15-20 KB.
LK was made by Travis Geiselbrecht see Github
The basic idea of this book is to think in patterns. Keep thing simples and bring you code in order. The humane brain for instance is a rule (pattern) extraction machine. Kids learn a language by extract the pattern of the language by listen all day long to the parents. Read Lernen-Gehirnforschung-die-Schule-Lebens
- Design Patterns - The Gang of Four
-
Jef Raskin - https://en.wikipedia.org/wiki/Jef_Raskin
-
Donald E. Knuth - https://de.wikipedia.org/wiki/Donald_E._Knuth
-
Niklaus Wirth - https://en.wikipedia.org/wiki/Niklaus_Wirth
-
Paul Graham - http://www.paulgraham.com/
-
Martin Fowler - https://martinfowler.com/
-
Robert C. Morris (Uncle Bob) - http://www.cleancoder.com/
-
Ken Tompson - [https://de.wikipedia.org/wiki/Ken_Thompson](Ken Thompson Wiki)
-
Dennis Ritchie - [https://www.bell-labs.com/usr/dmr/www/](Dennis Ritchie Homepage)
-
Rob Bike - [http://herpolhode.com/rob/](Rob Bike Homepage)
Several ways to increase the bus factor have been proposed:
- Reduce complexity
- Document all processes and keep that documentation up-to-date
- Encourage cross-training.
- Eric S. Raymond - The Art of Unix Programming
- Niklaus Wirth - The School of Niklaus Wirth: The Art of Simplicity
- Donald A. Norman - Living with Complexity - Chapter 1
Some interesting from the book Living with Complexity - Chapter 1
I distinguish between complexity and complicated. I use the word “complexity” to describe a state of the world. The word “complicated” describes a state of mind. The dictionary definition for “complexity” suggests things with many intricate and interrelated parts, which is just how I use the term. The definition for “complicated” includes as a secondary meaning “confusing,* which is what I am concerned with in my definition of that word. I use the word “complex” to describe the state of the world, the tasks we do, and the tools we use to deal with them. I use the word “complicated” or “confused” to describe the psychological state of a person in attempting to understand, use, or interact with something in the world. Princeton University’s WordNet program makes this point by suggesting that “complicated” means “puzzling complexity.”
I had a one day class about technial Writing documents held by Dr. Klaus Hofer from usabilitymapping.com
- Never build huge monolith software system.
You will after years always end with a Leaning Tower of Pisa In beginning you do not see that you build a leaning tower that will fall down. You will see it when it is to late.
- Build small modular components
Better is to build small components. Like small leaning towers. But if you see that one (of many) tower is going to become oblique then stop. Never build a tower with 54 levels if the tower is oblique on the first level.
A Software goes into production and the leaning towers is full of people you can not easy get refactor this building. This is the same with software. Never build monotlith. They will get monsters sooner or later. And then it is to late.
For example I believe Linux is a monolith compared to Plan9 OS or Oberon OS. Which is a much better approach.