Why We Build Simple Software
Simplicity in software development, likened to a Toyota Corolla's reliability, is crucial. Emphasizing straightforward tools and reducing complexity enhances reliability. Prioritizing simplicity over unnecessary features offers better value and reliability.
Read original articleThe article discusses the importance of simplicity in software development, drawing parallels with the reliability and efficiency of a Toyota Corolla car. Emphasizing the value of straightforward tools, the author highlights the benefits of reducing complexity in software to enhance reliability. By focusing on essential functions like code editing and running, platforms like Pickcode aim to provide a dependable user experience akin to a commuter car. The article warns against the pitfalls of unnecessary features in products, advocating for prioritizing simplicity to offer better value to consumers. It cautions against falling for marketing tactics that promote excessive features, emphasizing that simpler products are often more cost-effective and reliable. The piece underscores the significance of simplicity in software design and urges both developers and consumers to prioritize functionality over unnecessary complexity.
Related
Laziness is the source of Innovation and Creativity
Laziness can spur innovation in programming by encouraging efficiency and problem-solving. Embracing laziness responsibly can lead to creative and efficient solutions, promoting a balance between productivity and creativity.
The software world is destroying itself (2018)
The software development industry faces sustainability challenges like application size growth and performance issues. Emphasizing efficient coding, it urges reevaluation of practices for quality improvement and environmental impact reduction.
Self and Self: Whys and Wherefores (2009) [video]
The YouTube video discusses career and idea management, prioritization, Simula creation, structured programming, leadership in development, values in design, and efficient garbage collection. It mentions optimizing a Small Talk system in graduate studies.
Programmers Should Never Trust Anyone, Not Even Themselves
Programmers are warned to stay cautious and skeptical in software development. Abstractions simplify but can fail, requiring verification and testing to mitigate risks and improve coding reliability and skills.
Against Innovation Tokens
The article explores the concept of "innovation tokens" in technology selection, cautioning about operational overhead issues. Emphasis is on prioritizing ease of operation over development benefits, advocating for consistent technology choices.
No, it isn't. It is extremely complicated, containing two different mechanisms for propulsions, complex mechanical linkages for those propulsion mechanisms and steering, a deep web of electrical components including large software projects, augmenting the driving characteristics and providing essential safety features and much, much more.
It was painstakingly designed by thousands of engineers, who tried to take everything into account and to present to you something which to you "feels right", although you have zero idea about why it does.
Calling such a thing simple is completely ridiculous. As if the thousands of engineers were just superfluous and you could design a car by slapping together some components and have it work flawlessly. This is a highly integrated system, where a change to any single one component can influence all other components in very strange ways. That it is reliable, is not because it is simple, it is reliable because someone else has dealt with that complexity for you and spent an enormous amount of effort to get it right.
To be honest the arrogance of software developers is astounding. Looking at an enormously complicated project, which had to take into account a vast array of requirements and had to deal with all the complexity of mechanical, electrical and software systems working together and then going "that is simple, we should do simple things like they do", because the engineers working on it managed to hide all of that from you, speaks of so much arrogance. Just open up the hood and look at it. Look at it.
No car is simple and certainly not hybrid cars. Just consider the electronics: think 100+ ECUs communicating using dozens of different protocols over hundreds meters of wires, and millions of lines of code running on a diverse set of processors.
That car should have been in for at least 4 oil changes (maintenance) in that mileage -- more if not using synthetic oil.
Back in the day, we had these things called email clients. A good example was Eudora from Qualcomm (yes, the Snapdragon company). It was simple, straightforward, and handled sending, receiving, and managing emails with aplomb -- and nothing else.
Then Microsoft came along and combined email, contacts, and calendaring in one application -- Outlook. And ate the lunch of all the non-web-based email clients out there. To this day Outlook is pretty much table stakes for working in a corporate environment, especially since all corporate IT has to do is deploy Exchange to handle all three tasks from the server side. And Eudora is literally a museum piece; the software's source was made available as a historic artifact and the trademark rights were transferred to the Computer History Museum.
"Simplicity" in software is a red herring. You need to read your market and find out what your customers actually want, what will make life easier and more convenient for your actual users. Sometimes people actually want the car that grills hamburgers, the cellphone with a built-in camera, the email client that also does contacts and calendaring.
Life is complex (and often quite complicated). Most actual solutions that people need are solving complex problems. You can't really solve complex problems with simple software, you'll just end up building a complex (and often complicated) web of simple solutions.
Our job as software engineers is to prevent the software from getting complicated, managing the complexity such that it's able to morph as the users needs change over time.
To fit the article, adding a grill to a car would be complicating the car, not making it more complex.
Thats a pretty big strawman? This 'simple' car took thousands of people and many millions or billions of direct r&d. It has many more features than what was listed and it is fundamentally a complex beast. Reliability =/= simplicity.
Whatever software product your trying to sell that was build by a team of a half-dozen and mostly used off the shelf components is not a good comparison for the complexity of a car.
I'm sorry, what?
Please don't do this, people. It ruins completely good engines and the poor guy who gets this car with high mileage will be the one with the grenade on his hands.
Now with the software part. Keeping the software as "human sized" as possible and the ones who build it on the hook for support ( cheap paid support, not the main source of income of the contract ) is 80% of the work in order to keep complications in check.
Either way time and reality will weed out the ones who as "fancy" and "advanced" they are, nobody will have the money or patience to deal with them. The only unfortunate thing about this is how long it takes to play out and the victims it makes along the way until it succumbs under its own expensive weight.
Related
Laziness is the source of Innovation and Creativity
Laziness can spur innovation in programming by encouraging efficiency and problem-solving. Embracing laziness responsibly can lead to creative and efficient solutions, promoting a balance between productivity and creativity.
The software world is destroying itself (2018)
The software development industry faces sustainability challenges like application size growth and performance issues. Emphasizing efficient coding, it urges reevaluation of practices for quality improvement and environmental impact reduction.
Self and Self: Whys and Wherefores (2009) [video]
The YouTube video discusses career and idea management, prioritization, Simula creation, structured programming, leadership in development, values in design, and efficient garbage collection. It mentions optimizing a Small Talk system in graduate studies.
Programmers Should Never Trust Anyone, Not Even Themselves
Programmers are warned to stay cautious and skeptical in software development. Abstractions simplify but can fail, requiring verification and testing to mitigate risks and improve coding reliability and skills.
Against Innovation Tokens
The article explores the concept of "innovation tokens" in technology selection, cautioning about operational overhead issues. Emphasis is on prioritizing ease of operation over development benefits, advocating for consistent technology choices.