7 ms·

Bootloaders are small, but very important software. k/q is small but a very useful interpreter. There are so many examples, but it appears that to "the market

Bootloaders are small, but very important software. k/q is small but a very useful interpreter. There are so many examples, but it appears that to "the market" the most valued software development is large scale. The sentiment is create and contribute to large projects or go home. Stupid, but true. "Do one thing well" is more than just a UNIX philosophy. It is an essential truth. Most programs are lucky if they can do one thing "well". How many so-called "engineers" are afraid to write small, trivial programs lest they be laughed at? Large programs often become liabilities. Can we say the same for small programs? If it happens, write a new one. Maybe a user with an unmet need would rather have a program that does the one thing they want as opposed to one program that can allegedly do everything... whereby they are granted their wish through addition of "features". More internal complexity. And majority of users only using a fraction of the program's feature set. Waste.

nyan4 11y ago
> How many so-called "engineers" are afraid to write small, trivial programs lest they be laughed at? Very few. Engineers love simple and reliable stuff. You might be thinking CS graduates.
- lagadu 11y ago
  KISS has been a cherished principle for most of the past century and for good reason.
  - scholia 11y ago
    Indeed, the history of the development of very large software systems has been littered with disasters. Don't people read The Mythical Man-Month any more? http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...
    - ak39 11y ago
      Apparently not. Communication between team members has a huge cost factor ... not only ito dollar/time but also ito the quality of the final product.
  - d23 11y ago
    Maybe within a small bubble of people who understand. I thought the idea was self-evident, but after working with people whose instinctive response to every problem is to throw code at it, I can assure you it is not.
- 0xdeadbeefbabe 11y ago
  Not all engineers. Doesn't emacs represent a different philosophy than the unix philosophy? I'd find the reference, but I have a pile of software to deal with--what a predicament. I suspect that some engineers even make mistakes so they can heroically correct them later. I might be that engineer subconsciously.
- clock_tower 11y ago
  Indeed. I think the problem is that "engineer" has come to have two meanings: "engineer" and "computer programmer." The defining trait of an engineer is that he or she can't make innocent mistakes. If engineers sign off on a structure and it collapses, it's their fault; anyone who does that is civilly liable (i.e., able to be sued for damages), and, if memory serves, criminally liable as well if the mistake was negligent enough. That standard doesn't apply to computer programmers; programmers who want to be called engineers should try thinking about what their lives would be like if they, too, could be sued or imprisoned if they messed up. (They should also remember Paul Graham's point, at http://paulgraham.com/love.html http://paulgraham.com/love.html , that prestige is the after-effect of doing something well. Done well, anything -- even jazz or novel-writing -- can become prestigious. Done badly, anything can become disgraceful, and then it starts changing its name in order to pretend to be something less dishonorable. If you don't want to be called a programmer, it's because programmers are incompetent and personally disagreeable; do what you can to change that.)
ebiester 11y ago
It's the intercommunication with the web that becomes so painful. Users have no way to connect a stream of web applications, and the web disincentivized solving the corporate distribution problem.
- EvanPlaice 11y ago
  How so? The web is already standardized on REST as the 'universal' API. Publicly accessible microservices are becoming more and more common over time and some of them are being used to create integrations. Have you heard of Zapier? https://zapier.com/how-it-works/ https://zapier.com/how-it-works/ Slack bots also interact with other services: https://slack.com/apps/category/At0EFT67V3-new-noteworthy https://slack.com/apps/category/At0EFT67V3-new-noteworthy There's also the Huggin project: https://github.com/cantino/huginn https://github.com/cantino/huginn
  - ebiester 11y ago
    I am thinking more at the internal-software level. Consider an enterprise that has a simple case management app -- essentially, a help desk app for one portion of the business. There is another app within the system that was developed 5 years before to help choose when to start a case. It's maintained by a different team, so there's no natural coordination. If these were two Unix tools built like programmers would build, someone could connect the output of one, to a filter in the middle, to the input of the next. However, in the real organization, there is an individual who spends 20 hours a month to manually copy the information from app 1 to app 2 because the work to create a proper hypermedia interface. The combination of a corporate-aware Huginn (single sign on, etc) and a revolution in corporate apps that treated hypermedia as a first class citizen could make it happen. It's not happening now, however.
    - EvanPlaice 11y ago
      The problem with 'enterprisey' corporate applications has more to do with the culture of the developers who build those applications. Instead of breaking applications apart into distinct services they devs of corporate apps prefer to use OOP to create complex inter-dependent monolithic architectures. APIs for such apps are usually exposed by using a library, so a lot of emphasis is placed on access privileges at the language level (ie private/internal/public) instead of at the interface level (ie pipes/REST). The problem isn't that the capability doesn't exist, it's that corporations are either unaware or unwilling to experiment with alternative approaches. For example, one employee could spend half their time collecting data in Excel files from multiple members of a team, organizing it in a presentation-ready format, and emailing it up the chain. Alternatively, the team members could each have a Google Spreadsheet where they input the data and a timed trigger fires off a bot that processes the data, saves it to a new file, and emails the link up the chain. Both accomplish the same result. The second is a lot less prone to error/bias, and is also a lot more cost effective. But, to get an organization to adopt the latter approach requires convincing the organization to give up Excel as their canonical tool for organizing data. I have fought that battle and it's a lost cause. Even when adequate proof of cost/time savings are presented in a business-friendly format, inertia trumps reason. A company could theoretically hire a developer to deploy a digital assistant to streamline/automate the mundane and repetitive business processes. Except, devs are expensive, in short supply, and it's a really hard sell business leaders on the idea of adopting processes/tools that they don't fully understand.
pron 11y ago
While some small, simple programs are great, big economic contribution is mainly in large software: manufacturing control, ERP, air-traffic control, power-plant control etc.. Small software is great, but the big economic impact belongs to big software.
- jacquesm 11y ago
  There is no reason why 'big software' can not be made up out of small software pieces inter-operating. In fact those are the strongest and most maintainable systems.
  - jameshart 11y ago
    As soon as you've got a few hundred small pieces interoperating, you're not talking about something small any more.
    - jacquesm 11y ago
      That's true, but if you architect it well you should still be able to have an overview with every program as a functional block and inside the programs the scope should be limited enough that they are easy to understand. It's all a matter of balance. Good examples of such systems: message switches, telephone installations, routers, large scale web applications and so on. These are all very suitable to such decomposition into communicating processes.
      - pron 11y ago
        > These are all very suitable to such decomposition into communicating processes. That doesn't make them cheap to build; only possible.
        jacquesm 11y ago
        Better expensive than not for sale.
d23 11y ago
> "Do one thing well" is more than just a UNIX philosophy. It is an essential truth. Yes, thanks. My eye detects light and passes the signal on to my brain. It does it quite well. My liver removes toxins from my blood. It does it quite well. The big ball o mud made by BigCo is a hammer that reads the ambient temperature, weighs my nails, tells me the time, and predicts the outcome of futures markets. Is it any wonder it doesn't work worth a damn?
- anon4 11y ago
  Oh please. Your eyes are a system rife with bugs. You have a blind spot that exists for absolutely no good reason - the bundle of nerves can just as well connect to the back of the retina rather than the front. About 50% of people have a defective lens, which can only be corrected by putting yet another lens in front of it (in frames, directly on the eyeball or by ablating the eyeball in order to turn it into a lens). You can be near-sighted AND far-sighted at the same time. Your eyeballs contain imperfections called floaters that your body has no way of removing, so your brain learns to filter them out. You constantly see your own nose. Some people's eyes are misaligned and they have no depth perception. The colour violet doesn't exist, your red cones are actually activating in response to your blue cones detecting high-frequency blue light. And I don't mean they activate in response to the light, physically the red cones don't detect any of the wavelengths of violet light - they're just wired up in such a way that a low activation of the blue cones triggers activation of the red cones. Some people have a defect that makes their red cones activate in response to wavelengths too close to green light, so they can't tell the two apart. Some are just completely colour-blind. Oh, and the image you get in your eyes is rotated 180 degrees. Your eyes most definitely don't do just one thing and they most certainly don't do it all that well. But they do an important job reasonably well, which is what strive for in any large software system.
  - d23 11y ago
    You're right. It's only one of the most complex and intricate pieces of machinery in the universe, enabling billions of organisms around the planet to build a realistic, 3-dimensional picture of the world around them by picking up hundreds of millions of bits of information from the fastest moving particles known to man. It's about on par with Microsoft Word.

nyan4 11y ago

> How many so-called "engineers" are afraid to write small, trivial programs lest they be laughed at? Very few. Engineers love simple and reliable stuff. You might be thinking CS graduates.

lagadu 11y ago
KISS has been a cherished principle for most of the past century and for good reason.
- scholia 11y ago
  Indeed, the history of the development of very large software systems has been littered with disasters. Don't people read The Mythical Man-Month any more? http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ http://www.amazon.com/Mythical-Man-Month-Software-Engineerin...
  - ak39 11y ago
    Apparently not. Communication between team members has a huge cost factor ... not only ito dollar/time but also ito the quality of the final product.
- d23 11y ago
  Maybe within a small bubble of people who understand. I thought the idea was self-evident, but after working with people whose instinctive response to every problem is to throw code at it, I can assure you it is not.
0xdeadbeefbabe 11y ago
Not all engineers. Doesn't emacs represent a different philosophy than the unix philosophy? I'd find the reference, but I have a pile of software to deal with--what a predicament. I suspect that some engineers even make mistakes so they can heroically correct them later. I might be that engineer subconsciously.
clock_tower 11y ago
Indeed. I think the problem is that "engineer" has come to have two meanings: "engineer" and "computer programmer." The defining trait of an engineer is that he or she can't make innocent mistakes. If engineers sign off on a structure and it collapses, it's their fault; anyone who does that is civilly liable (i.e., able to be sued for damages), and, if memory serves, criminally liable as well if the mistake was negligent enough. That standard doesn't apply to computer programmers; programmers who want to be called engineers should try thinking about what their lives would be like if they, too, could be sued or imprisoned if they messed up. (They should also remember Paul Graham's point, at http://paulgraham.com/love.html http://paulgraham.com/love.html , that prestige is the after-effect of doing something well. Done well, anything -- even jazz or novel-writing -- can become prestigious. Done badly, anything can become disgraceful, and then it starts changing its name in order to pretend to be something less dishonorable. If you don't want to be called a programmer, it's because programmers are incompetent and personally disagreeable; do what you can to change that.)

ebiester 11y ago

It's the intercommunication with the web that becomes so painful. Users have no way to connect a stream of web applications, and the web disincentivized solving the corporate distribution problem.

EvanPlaice 11y ago
How so? The web is already standardized on REST as the 'universal' API. Publicly accessible microservices are becoming more and more common over time and some of them are being used to create integrations. Have you heard of Zapier? https://zapier.com/how-it-works/ https://zapier.com/how-it-works/ Slack bots also interact with other services: https://slack.com/apps/category/At0EFT67V3-new-noteworthy https://slack.com/apps/category/At0EFT67V3-new-noteworthy There's also the Huggin project: https://github.com/cantino/huginn https://github.com/cantino/huginn
- ebiester 11y ago
  I am thinking more at the internal-software level. Consider an enterprise that has a simple case management app -- essentially, a help desk app for one portion of the business. There is another app within the system that was developed 5 years before to help choose when to start a case. It's maintained by a different team, so there's no natural coordination. If these were two Unix tools built like programmers would build, someone could connect the output of one, to a filter in the middle, to the input of the next. However, in the real organization, there is an individual who spends 20 hours a month to manually copy the information from app 1 to app 2 because the work to create a proper hypermedia interface. The combination of a corporate-aware Huginn (single sign on, etc) and a revolution in corporate apps that treated hypermedia as a first class citizen could make it happen. It's not happening now, however.
  - EvanPlaice 11y ago
    The problem with 'enterprisey' corporate applications has more to do with the culture of the developers who build those applications. Instead of breaking applications apart into distinct services they devs of corporate apps prefer to use OOP to create complex inter-dependent monolithic architectures. APIs for such apps are usually exposed by using a library, so a lot of emphasis is placed on access privileges at the language level (ie private/internal/public) instead of at the interface level (ie pipes/REST). The problem isn't that the capability doesn't exist, it's that corporations are either unaware or unwilling to experiment with alternative approaches. For example, one employee could spend half their time collecting data in Excel files from multiple members of a team, organizing it in a presentation-ready format, and emailing it up the chain. Alternatively, the team members could each have a Google Spreadsheet where they input the data and a timed trigger fires off a bot that processes the data, saves it to a new file, and emails the link up the chain. Both accomplish the same result. The second is a lot less prone to error/bias, and is also a lot more cost effective. But, to get an organization to adopt the latter approach requires convincing the organization to give up Excel as their canonical tool for organizing data. I have fought that battle and it's a lost cause. Even when adequate proof of cost/time savings are presented in a business-friendly format, inertia trumps reason. A company could theoretically hire a developer to deploy a digital assistant to streamline/automate the mundane and repetitive business processes. Except, devs are expensive, in short supply, and it's a really hard sell business leaders on the idea of adopting processes/tools that they don't fully understand.

pron 11y ago

While some small, simple programs are great, big economic contribution is mainly in large software: manufacturing control, ERP, air-traffic control, power-plant control etc.. Small software is great, but the big economic impact belongs to big software.

jacquesm 11y ago
There is no reason why 'big software' can not be made up out of small software pieces inter-operating. In fact those are the strongest and most maintainable systems.
- jameshart 11y ago
  As soon as you've got a few hundred small pieces interoperating, you're not talking about something small any more.
  - jacquesm 11y ago
    That's true, but if you architect it well you should still be able to have an overview with every program as a functional block and inside the programs the scope should be limited enough that they are easy to understand. It's all a matter of balance. Good examples of such systems: message switches, telephone installations, routers, large scale web applications and so on. These are all very suitable to such decomposition into communicating processes.
    - pron 11y ago
      > These are all very suitable to such decomposition into communicating processes. That doesn't make them cheap to build; only possible.
      - jacquesm 11y ago
        Better expensive than not for sale.

d23 11y ago

> "Do one thing well" is more than just a UNIX philosophy. It is an essential truth. Yes, thanks. My eye detects light and passes the signal on to my brain. It does it quite well. My liver removes toxins from my blood. It does it quite well. The big ball o mud made by BigCo is a hammer that reads the ambient temperature, weighs my nails, tells me the time, and predicts the outcome of futures markets. Is it any wonder it doesn't work worth a damn?

anon4 11y ago
Oh please. Your eyes are a system rife with bugs. You have a blind spot that exists for absolutely no good reason - the bundle of nerves can just as well connect to the back of the retina rather than the front. About 50% of people have a defective lens, which can only be corrected by putting yet another lens in front of it (in frames, directly on the eyeball or by ablating the eyeball in order to turn it into a lens). You can be near-sighted AND far-sighted at the same time. Your eyeballs contain imperfections called floaters that your body has no way of removing, so your brain learns to filter them out. You constantly see your own nose. Some people's eyes are misaligned and they have no depth perception. The colour violet doesn't exist, your red cones are actually activating in response to your blue cones detecting high-frequency blue light. And I don't mean they activate in response to the light, physically the red cones don't detect any of the wavelengths of violet light - they're just wired up in such a way that a low activation of the blue cones triggers activation of the red cones. Some people have a defect that makes their red cones activate in response to wavelengths too close to green light, so they can't tell the two apart. Some are just completely colour-blind. Oh, and the image you get in your eyes is rotated 180 degrees. Your eyes most definitely don't do just one thing and they most certainly don't do it all that well. But they do an important job reasonably well, which is what strive for in any large software system.
- d23 11y ago
  You're right. It's only one of the most complex and intricate pieces of machinery in the universe, enabling billions of organisms around the planet to build a realistic, 3-dimensional picture of the world around them by picking up hundreds of millions of bits of information from the fastest moving particles known to man. It's about on par with Microsoft Word.