http://www.joelonsoftware.com/items/2009/09/23.html Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
If you write code, read this.
Started by ●September 24, 2009
Reply by ●September 24, 20092009-09-24
Jerry Avins wrote:> http://www.joelonsoftware.com/items/2009/09/23.html >I don't know the author; I found the text in one of the American-Russian forums and translated it. //=========================== Any Russian Programmer� After a two-minute look at a code, any Russian programmer will certainly jump up and say to himself: all of that should be rewritten! Then he will feel some doubts about how much time it would take, and he will spend the rest of the day trying to convince himself that it only seems to be a lot of work. Sure, if he would work at this seriously, everything could be done. Then, the code would be correct and beautiful. Next morning, the Russian programmer looks sharp and very proud as he reports to the boss that it would take no more then a day to rewrite that piece of code. Yes, no more then a day. Maybe two days, in the worst case, if all risks are taken into account. As a result, the boss gives him a week. The process is successfully completed in half a year. Until the code will be revised by some other Russian programmer. In the meantime, four Chinese programmers keep doing their hard work in four adjacent cubicles without stopping for a second. They come to work much earlier and leave much later then the Russian programmer; however, they somehow manage to accomplish about three times less. Those four haven�t written anything new for a while, and only support the code that was created in its time by the Hindu and rewritten twice by two different Russians. This code is not just infested by bugs; it is a stronghold of bugs. From here, the bugs are continuously recreated by the favorite Chinese technology of code reuse: Copy/Paste. The bugs are spread by static variables and references to the static variables (It is well known that no Chinese programmer can tolerate the inconvenience of not been able to access a variable directly). When the Russian programmer remembers about these variables and references, he loses the clarity of his speech. He starts swearing in Russian and English at the same time. For a long time, he has been dreaming of rewriting the whole piece of code on which the Chinese are working, but he doesn�t have time to do that. He is already rewriting two big modules, and he just proved to the boss that the third module has to be rewritten as well. Besides, the Russian programmer tries not to offend the Chinese programmers. By the way, his concerns are in vain; the Chinese have already decided that the Russian is trying to push them out of work. The Chinese are responsible for serious bugs in the code. The boss knows about it and he hurries them. The Chinese respect the boss; that�s why they are trying to hang the bugs on each other. They know that all attempts to fix the bugs will only result in the creation of new bugs. That will only make the situation worse. And they are very right about it. The only man in the company who knows how those static variables change their values is the Hindu. But he is meditating. That�s why all four of the Chinese will be let go at the time of the next layoff� But who else should be let go? The Russian is still not finished rewriting his code, and the Hindu - the most valuable asset of the company - rarely pays any attention to the project, but, when he does, everybody understands that no one knows the software architecture better then he does. So, after the Chinese are fired, their code can have two different fates. The first � the Russians will get it, and they will rewrite it. The second - the local Canadian programmer will get it. Yes, the Canadian programmer is a special character. He rushes like a knight to fix the most fearsome Chinese bug. This Bug has already dwelt inside the code for three years, and the Chinese have already reported to the boss that the bug is fixed four times (each of the programmers reported it once). But the Bug returned every time, like Batman to Gotham City. The Canadian programmer, raised on the heroic pathos of American football, rushes into battle headfirst, doing what the Chinese haven�t risked doing for three long years. He will find a place where the static variable takes a value of 1 instead of the correct value of 0, and resolutely add the other variable with the correct value nearby. The Bug will perish in an unequal battle with the hero. However, victory will be achieved by a high price. Everything will quit working, including the code that was just rewritten by the Russian programmer. This will put the Russian programmer deep into thought for two days. After that, he will come to the predictable conclusion that the design was wrong from the very beginning, and everything has to be redone. This task will probably take a week. Yes, surely no more than a week. The Canadian programmer will bravely rush to fix everything, and everything will become worse, even though it seemed... This commotion will bring the Hindu out of his meditation, who will come up with a completely genius solution � branch the code out. According to his plan, we would now support two versions of the same code � one working, but with the Bug, the other without the Bug, but not working. The Russian programmer, hearing of this plan, will break his ruler over the table and call his wife an idiot, but will not dare to disagree at the meeting. Fortunately, this won�t significantly affect the company�s dealings, since the product is still sold. That�s why the management is generally satisfied, and does not tire of reminding everybody that they are picked as the best from the best. And that we have long ago proved our ability to release the product, since we occasionally release it. //=============================== VLV
Reply by ●September 24, 20092009-09-24
Vladimir Vassilevsky wrote:> > > Jerry Avins wrote: > >> http://www.joelonsoftware.com/items/2009/09/23.html >> > > I don't know the author; I found the text in one of the American-Russian > forums and translated it. > > //=========================== > Any Russian Programmer� > > After a two-minute look at a code, any Russian programmer will certainly > jump up and say to himself: all of that should be rewritten! Then he > will feel some doubts about how much time it would take, and he will > spend the rest of the day trying to convince himself that it only seems > to be a lot of work. Sure, if he would work at this seriously, > everything could be done. Then, the code would be correct and beautiful.Maybe my Russian ancestry shows a bit! Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●September 24, 20092009-09-24
On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote:> http://www.joelonsoftware.com/items/2009/09/23.html > > JerryNo one has ever come to me years after I released some engineering work and said "damn, but it's nice that you got that done so quick". But they have come to me years -- decades, even -- and said "You schmuck*! Your code is broken!". Perhaps if you're working on consumer goods you can have that sort of attitude -- but would you want to live in a house built with that lack of care? How about the software that runs the anti-lock brakes on your car? Get a pacemaker whose code is written by that guy? Know that the nations warplanes, ships, bombs and fighting vehicles depend on software written by that guy? Think about it... * Well, "schmuck" with four letters. -- www.wescottdesign.com
Reply by ●September 24, 20092009-09-24
Tim Wescott <tim@seemywebsite.com> wrote:> Jerry Avins wrote: > > > http://www.joelonsoftware.com/items/2009/09/23.html > > > > Jerry > > No one has ever come to me years after I released some engineering > work and said "damn, but it's nice that you got that done so quick". > But they have come to me years -- decades, even -- and said "You > schmuck*! Your code is broken!". > > Perhaps if you're working on consumer goods you can have that sort of > attitude -- but would you want to live in a house built with that lack > of care? How about the software that runs the anti-lock brakes on > your car? Get a pacemaker whose code is written by that guy? Know > that the nations warplanes, ships, bombs and fighting vehicles depend > on software written by that guy?You have a point. However, if you get something that works part of the time then you can use it to test other things. And if something is being done that requires a complex software project, there's a strong chance there will be something broken elsewhere. Broken hardware, broken specs, broken fundamental concepts, broken physics, etc. There's a pretty good chance that they won't find out what else is wrong until they get working software to reveal the problems. It isn't real good to have code that sometimes fails and it takes effort to find out whether it's the code or something else that failed. But that's a whole lot better than not having code to test at all. So there's a lot to be said for starting with some sort of bare-bones prototype that does just enough to test out the system. And then get a proof-of-concept that shows basicly what you think can be done and how. And a test user interface so potential users can tell you what's wrong with it. And then an attempt at a real product that's still as much as possible simple. And maybe then you can start work on the product that does everything right, while you go on maintaining and improving the existing product that's bringing in the money to pay for the development effort. If the really good system never gets released, at least you have something.
Reply by ●September 24, 20092009-09-24
>On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote: > >> http://www.joelonsoftware.com/items/2009/09/23.html >> >> Jerry > >No one has ever come to me years after I released some engineering work >and said "damn, but it's nice that you got that done so quick". But they>have come to me years -- decades, even -- and said "You schmuck*! Your >code is broken!". > >Perhaps if you're working on consumer goods you can have that sort of >attitude -- but would you want to live in a house built with that lack of>care? How about the software that runs the anti-lock brakes on your >car? Get a pacemaker whose code is written by that guy? Know that the >nations warplanes, ships, bombs and fighting vehicles depend on software>written by that guy? > >Think about it... > >* Well, "schmuck" with four letters.That sounds seriously naive. Of that list I've worked on warplanes, ships and bombs. You might be horrified if you saw the standard of the software that goes into these. Regards, Steve
Reply by ●September 24, 20092009-09-24
>Tim Wescott <tim@seemywebsite.com> wrote: >> Jerry Avins wrote: >> >> > http://www.joelonsoftware.com/items/2009/09/23.html >> > >> > Jerry >> >> No one has ever come to me years after I released some engineering >> work and said "damn, but it's nice that you got that done so quick". >> But they have come to me years -- decades, even -- and said "You >> schmuck*! Your code is broken!". >> >> Perhaps if you're working on consumer goods you can have that sort of >> attitude -- but would you want to live in a house built with that lack >> of care? How about the software that runs the anti-lock brakes on >> your car? Get a pacemaker whose code is written by that guy? Know >> that the nations warplanes, ships, bombs and fighting vehicles depend >> on software written by that guy? > >You have a point. However, if you get something that works part of the >time then you can use it to test other things. > >And if something is being done that requires a complex software project, >there's a strong chance there will be something broken elsewhere. Broken >hardware, broken specs, broken fundamental concepts, broken physics, >etc. > >There's a pretty good chance that they won't find out what else is wrong >until they get working software to reveal the problems. > >It isn't real good to have code that sometimes fails and it takes effort >to find out whether it's the code or something else that failed. But >that's a whole lot better than not having code to test at all. > >So there's a lot to be said for starting with some sort of bare-bones >prototype that does just enough to test out the system. And then get a >proof-of-concept that shows basicly what you think can be done and how. >And a test user interface so potential users can tell you what's wrong >with it. And then an attempt at a real product that's still as much as >possible simple. > >And maybe then you can start work on the product that does everything >right, while you go on maintaining and improving the existing product >that's bringing in the money to pay for the development effort. If the >really good system never gets released, at least you have something.Criticism of the "get something useful out the door in a reasonable time" attitude assumes there is a superior alternative. I've never seen one. In general, the more "rigorous" the process, the worse the outcome. Steve
Reply by ●September 24, 20092009-09-24
Tim Wescott wrote:> On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote: > >> http://www.joelonsoftware.com/items/2009/09/23.html >> >> Jerry > > No one has ever come to me years after I released some engineering work > and said "damn, but it's nice that you got that done so quick". But they > have come to me years -- decades, even -- and said "You schmuck*! Your > code is broken!". > > Perhaps if you're working on consumer goods you can have that sort of > attitude -- but would you want to live in a house built with that lack of > care? How about the software that runs the anti-lock brakes on your > car? Get a pacemaker whose code is written by that guy? Know that the > nations warplanes, ships, bombs and fighting vehicles depend on software > written by that guy?I don't think you groked the kind of programmer Joel praises. I see myself. One of my first embedded jobe was a box to offload an Auger spectrometer from the minicomputer that controlled it. To wash out drift in the spectrometer's high-voltage supply, brief readings were taken at each level, the level stepped to the end, then the whole process repeated. The results at each level were accumulated. That way, drift affected only the base line, moving it up or down as a whole. Without that approach (or fixing the programmable supply) the baseline would have been tilted or even curved. I built an interface that the mini could instruct, supplying starting point, step size, and number of steps. The interface box then ran the spectrometer, collecting 24-bit sums for the bins, and signaling the mini when it was ready to deliver the results. Mini usage went from 98% devoted to the spectrometer to less than 1%. The machine used 3Kx8 of data memory, 64 bytes of working RAM, and 128 bytes of program EPROM. (Those were early days.) I ran the 1802 on a 100KHz clock. It was plenty fast enough for the job and I thought it mighr increase reliability. It ran for about 12 years without attention, when a young fellow came to my desk and asked for help deciphering the EPROM code. He wanted to add a new function. I astonished him by getting my copy of the documention out of my file. (The materials lab had long since lost their copy.) The original code occupied 127 actual bytes, and I had hedged my bets by wiring the ROM socket to accept up to 1K. I coded up his addition while he waited and sent him back with the new EPROM. It worked right off. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●September 25, 20092009-09-25
On Sep 24, 5:23�pm, Jerry Avins <j...@ieee.org> wrote:> http://www.joelonsoftware.com/items/2009/09/23.html > > Jerry > -- > Engineering is the art of making what you want from things you can get. > �����������������������������������������������������������������������I think there's some truth in the article, but I don't believe it's completely accurate. Things held together with duct tape can rarely be built upon --- add one thing and it's likely to break. In a previous life, I did some programming for an engineer. We did have to ship an actual product. The goal was to implement a set of hardware control functions for a microcontroller. The engineer had a list of the functions he needed, and the data structures defined. Sounds like a straight forward task. But I was also familiar with an existing higher level API, developed by another group, to encapsulate such hardware control functions. The abstraction layer provided by the API allowed new control functions to be added easily. The only problem was that the code to implement the abstraction layer was written for PC class machines, and at the outset, it was not clear whether or not a reduced version could be made to fit into the resource-limited microcontroller platform. When I proposed the idea of using the API to the engineer, I could sense a roll of the eyes. But, after a little resistance, he went along with it -- of course I had to do the standard sales pitch painting a utopian picture of how the solid foundation would last for centuries and would eventually grow to encompass all things. Long story short, I got a suitable port of the API and hardware functions working, but also took flak for doing the project in about two weeks instead of the allotted four or five days. I think my instincts were right in that case, though, as the code never caused problems, at least none which I heard about in this life, and was reportedly reused for the flexibility of the API. I've also had a failure or two of the sort described in the article, but of course I don't want to dredge those up! Krishna
Reply by ●September 25, 20092009-09-25
Tim Wescott wrote:> On Thu, 24 Sep 2009 18:23:04 -0400, Jerry Avins wrote: > > >>http://www.joelonsoftware.com/items/2009/09/23.html >> >>Jerry >> Perhaps if you're working on consumer goods you can have that sort of > attitude -- but would you want to live in a house built with that lack of > care? How about the software that runs the anti-lock brakes on your > car? Get a pacemaker whose code is written by that guy? Know that the > nations warplanes, ships, bombs and fighting vehicles depend on software > written by that guy?Do you seriously believe that somewhere in Zen there is a sinecure of superprogrammers who write stuff according to the carefully prepared technical plans? How naive of you. Those are the same clueless stupidents that you can see anywhere, and the code is a pitiful crap. The reality is that it is cheaper to take risks and pay expenses then get the things done as prescribed in textbooks. Especially as the projects are been developed by big teams, and the law of big numbers comes into play. VLV
