3 ms·

Our world is made of spit and bailer twine. The only difference is the skill at which one uses spit and bailer twine. IIRC LCD panels still have a manufacturing

• StavrosK 15y ago
  > It's only those of us who see spit and bailer twine as all we need that can manage to turn a hacky property of silicon into NAND gates and from NAND gates an iPhone. Are you seriously suggesting that the same train of thought that "rubs wool on LCDs because it 'makes them work'" was responsible for turning silicon into an iPhone?
  • fleitz 15y ago
    Yes, there are those that would refuse to rub wool because it's a voodoo step. Those people will never turn silicon into iPhones because they let not knowing stand in the way of creating solutions. The first software that I wrote professionally was atrocious, hacky as hell, but it worked. I didn't let the fact that I didn't know how to program stand in the way of creating a solution. I probably could have spent a year reading books and writing practice software and the solution I came up with would have been much more elegant, but it wouldn't have mattered, they needed a solution today, not next year when I might have understood writing software at a much better level. I'm suggesting that knowing that something does work is far more important than knowing how it works, or why it works. Whilst I'm sure LCD manufactures have their scientists on understanding that part of the manufacturing process in the meantime they'll do their voodoo wool rub because it works. Maybe the wool rub with the plastic in the LCD disrupts the higgs field, who knows. Rubbing wool on an LCD because it works is an example of spit and bailer twine 'engineering'. Similarly, the first transistor was a massive hack, but a huge step forward for technology. I'm not advocating ignorance, I'm just saying that those who are ignorant can make huge steps forward, eg. the first guy who rubbed wool on an LCD. I'm sure the original facebook code had SQL statement embedded next to HTML; everyone knows it's a bad idea, but despite that you can put the foundations in place to make a huge business. The important thing is solving problems, not the elegance of the solution. Be a wright brother, make an airplane despite the fact that no one knows how. Solve a problem first, make it elegant second.
    • Jach 15y ago
      > Yes, there are those that would refuse to rub wool because it's a voodoo step. Those people will never turn silicon into iPhones because they let not knowing stand in the way of creating solutions. My own objection would be: does it really work? If we can determine that yes, in fact, it does, then I want to know why, but I'd continue doing it until we know why. When you know why, you can make it better. Until then, you're still just shotgun testing. Not that shotgun testing can't work, but if you can do better, and you can afford the resources to learn how to do better, you probably should. I would agree the best is the enemy of the good enough, but also of the better--if all you know are so-called "best practices" and never deviate you'll never improve. You have to answer the question for your particular case though of whether deviations are likely to result in an improvement any time soon. I don't really understand why, in this particular case, some people would stop the method without a replacement, just on principle of not understanding it. This isn't the first case I've heard of such things though--I've heard of some developers on a team deleting large swathes of code they didn't understand, replacing it with something they wrote that doesn't even work nearly as well. (One of my roommates says for a robot project one of his teammates took apart a working breadboarded controller but still hasn't replaced it with anything.) > Solve a problem first, make it elegant second. "If you nail simple and fast, elegant is usually forced to come along for the ride.." ( http://twitter.com/#!/1/statuses/122368755962621952 http://twitter.com/#!/1/statuses/122368755962621952 ) I don't think elegance is at odds with solving a problem, but in general I agree that getting something working that's good enough now beats something that would have been better later. But not always, and possibly not even most of the time, as the time spent in the programming world rewriting and reinventing things shows.
  • ajuc 15y ago
    Fun (IMHO) story: My uncle was hired in 90' as a consultant engineer in a factory (they produced parts for Deawoo car factory in Poland). The plastic parts of the inside part of the roof was heated up, and pressed into proper shape, and the process was somehow undetermined - sometimes the product was ok, often it was not. Workers at the line developed some routines that helped (voodoo, like touching the machine in just the right moment, after a few seconds of heating, or making short pauses after a few roofs produced). They argued whose "magic touch" is better :) That helped (according to them), but still big percentage of roofs were broken. My uncle found the source - one temperature detector was not connected to the machine, the cable instead touched the case of the machine. But that machine was used for a few years already, and the "voodo" was helpful in geting the job done in the meantime. Yes - they should investigate the root cause earlier, but the owner wasn't interested in investing any money in the tooling after initial investition, and just blamed "uneducated" workers for big percentage of broken products.