6 ms·

[update: I've got hold of some of the code. Here's a copy of one of the programmes http://pastie.org/4615158 http://pastie.org/4615158] I have an awesome story

[update: I've got hold of some of the code. Here's a copy of one of the programmes http://pastie.org/4615158 http://pastie.org/4615158] I have an awesome story that i think I've told before, but I'll tell it again anyway :) My father-in-law is a pharmasist. back in the early 90s computers were starting to make their way into Pharmacy and the first few pharmacy sortware packages appeared. this increased with time, as you'd expect. At some point he decided it was inevitible but he decided (I have no idea why, except that he's always been quite independent) he'd write his own software. Took himself off to nightschool and learned dBase III. He'd never written a line of code prior to this. He then proceeded to write an entire pharmacy suite of software tools that are still in use. They've been heavily updated and added to over the last 20 years but it's still all DBase III running on DOS. It's a saggering amount of code over hundreds of files but it all works. I've seen the code and it wouldn't pass a first semester coding course. each programme is a single 10,000 line spaghetti-fest. I've tried to explain functions/methods to him but he didn't understand and in the end I gave up. apparently he doesn't need them! I can't understate how complex this software is - it's stock control, point of sale (including the usual things like birthday vouchers, discounts accounts etc etv), prescription dispensing, patient records etc. everything for a modern pharmacy. The australian health dept know about it and it's met all their criteria. it does everything. It's mindbogglingly awfull bad code by any metric imaginable but yet it's robust, appears to be as-good-as bug free and has been able to be maintained (gov regulations for pharmacy change constantly so it's required major changes each year to keep up to date) and in production use for almost 20 years. oh, and it's fast :) [Edit: looking at the other comments it seems I've replied to the wrong thing. I was actually writing a comment in response to this http://prog21.dadgum.com/87.html http://prog21.dadgum.com/87.html (Write Code Like You Just Learned How to Program) which was linked to from the main article]

schmrz 14y ago
I wonder how much that initial version changed during the 20 years of maintenance. I find it hard to believe that someone was maintaining it for 20 years without improving the quality (of the code/design) and making it easier to maintain. Have you seen the code base of the initial version or of the version that is currently being used?
- notimetorelax 14y ago
  To be fair I know of programmers that hack their code until it works and then they forget about it. Next time they need to change something: take the ax and hack away...
- cubicle67 14y ago
  I've know my wife for the last 18 or 19 years and it was written before that, so I haven't seen the original. I have seen him debugging code in the evenings though. This consisted of printing out the entire programme (in the DBase sense a "programme" is a single file, but a programme in our sense would be a collection of dbase programmes) and the paper (dot matrix, so it's all connected) trailing all thruought the house as he draws pencil lines all over it to reconstruct programme flow. no indentation at all The short answer to your question is no, I didn't see any evidence of improved structure or practices at all. All variables global. goto ftw. no procedures/methods/functions at all. He's never even heard of the concept when I tried to explain. [Edit: managed to get hold of some of the code (see parent) and it looks like I was wrong on the indentation - he did start to use it at some point]
  - slurgfest 14y ago
    closely looking at a printout is an underrated archaic practice.
    - ams6110 14y ago
      Ah yes "desk checking." When compiles took hours or would only run during the overnight batch cycle. You better believe it was worth spending some time manually reviewing your code.
  - schmrz 14y ago
    I'm not sure if that's scary or awesome. Probably both. Thanks for sharing!
- kamaal 14y ago
  You find it hard to believe because you are convinced it can't be done other wise. Once you see some one doing it you will believe otherwise.
kamaal 14y ago
This reminds me of a manager of mine who wrote a 10,000 line Perl script. He thought himself how to write Perl in a week. And then started coding. He wrote a script to automate a very tedious testing process so perfectly, we were able to reduce our test team by like 70% and test more precisely than before. It was fully procedural code. And it looked monstrous. Our architect challenged him that it won't workout. He even challenged to rewrite it in Java, but that project never finished. He was never able to ever complete the rewrite. It motivated me to learn Perl. Since then my life has been totally different. I've done mountains of work alone working, hacking during nights. I learned the following things from that episode: 1. First write the program. 2. Write the correct program. 3. Write the program to run fast and efficient(scalability and all that) 4. Beautify the program. But most people never cross 2)- The point is there are tons of people who can do this tasks related to micro optimization. The people who win in a ordinary work environment are ones who know the art of converting ideas to sell able products in the fastest way possible. By the way that manager also wrote database clients in C++ which helped us troubleshoot our in memory databases from remote locations. Again the architect challenged to get it done Java, as before the project never completed :) Its a fact that majority of the software world is hacked and held in existence with tools like Perl and Php. The people who care about artistic elegance are few, they often fail and generally don't matter.
- arethuza 14y ago
  Isn't your list a variation on the well known list of: - Make it work - Make it right - Make it fast http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
  - alexfoo 14y ago
    Depends on whether step 2 is a complete rewrite (in a different language) or further hacking to "make it right". My process tends to be: 1. Make it work - Knock up a prototype (lots of assumptions made and noted, limited error checking, etc) 2. Make it right - By starting from scratch and use what was learned in making the prototype 3. Make it fast(er) - Having a prototype, and trying it at scale, should have already given me an idea of what algorithms/structures to use/avoid in Stage #2 but, obviously, a further optimisation stage will almost always be beneficial. Ideally (if time allows) the prototype is written in a completely different language to the desired target. This is the most important point. Most of the production code I write is C and I tend to do my prototypes in Perl. The helps me for several reasons: a) ADTs (lists, hashes/dictionaries, etc) are just easier/quicker in Perl/python/ruby than in C (I do have my own C library that I reuse for ADTs so it's not as if it's a great chore writing them each time, but ADT instantiation is just easier in Perl/python/ruby than C). b) It's also easier to play around with different algorithms if you can switch between ADTs more easily. c) I can use the prototype stage to continue to learn new languages (it used to just be Perl but has extended to include languages like Python and ruby). This list will keep on growing. d) It prevents me (or the business) stopping at Stage #1 and using the prototype code for production. (This could be even worse if the prototype was written in C.) e) A prototype, being quicker to knock up, means faster to getting it in-front of someone else to look at and give feedback. f) It prevents me just copy-and-pasting chunks of the prototype code as production code so I, hopefully, don't carry over any of the assumptions I'd made in creating the prototype. g) "Knock up a prototype" doesn't mean no design/testing/etc. I usually end up with design notes and some automated black box testing that can be reused in the later stages.
thewarrior 14y ago
I would like to make a few points , This is only possible because your dad is the only one who has to deal with this program and also he only works on this one big complex thing which he knows really well .
- cubicle67 14y ago
  oh hell yeah, absolutely. This sort of code is not uncommon at all but is pretty much incomprehensible (let alone maintainable) for anyone beyond the original implementer
  - Tycho 14y ago
    If one day somebody else does inherit the codebase, are there any tools out there that are designed to help people in that situation? Like something that de-spaghettifies everything?
    - koide 14y ago
      Appropriately, it's a book: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea... Some automatic tools could help (although I doubt thay'll work on DBase III): Static analysis to see what's there, version control to start at the top and log your way through and be able to rollback to a previous working version. But it's at the very least weeks of pain.
ajuc 14y ago
Because understanding exactly what program should do is more important than understanding what are best practices in CS, or how to abstract things. If you can keep all interactions of your app in your head, then it doesn't matter how badly designed the code is. Architecture is only important because it makes it possible to change things without understanding the whole thing. And complete understanding with bad architecture beats good architecture with incomplete understanding.
- kamaal 14y ago
  >Architecture is only important because it makes it possible to change things without understanding the whole thing. And for that you need to understand the architecture, ofcourse. You always need to understand something_(n-1) to understand something_n, ad infinitum
  - ajuc 14y ago
    It's a fractal, yes, but you can do with only understanding your branch in the highest resolution, you don't need all the details of the whole system (if it's well designed).
- arethuza 14y ago
  I've never seen anything labelled a "best practise" that has had anything to do with what I would call CS.
anabis 14y ago
The version given to me by my professor was: "Think like an amateur. Execute as an expert." Originally by Takeo Kanade. ( http://www.cs.cmu.edu/interviews/kanade/ http://www.cs.cmu.edu/interviews/kanade/ )

schmrz 14y ago

I wonder how much that initial version changed during the 20 years of maintenance. I find it hard to believe that someone was maintaining it for 20 years without improving the quality (of the code/design) and making it easier to maintain. Have you seen the code base of the initial version or of the version that is currently being used?

notimetorelax 14y ago
To be fair I know of programmers that hack their code until it works and then they forget about it. Next time they need to change something: take the ax and hack away...
cubicle67 14y ago
I've know my wife for the last 18 or 19 years and it was written before that, so I haven't seen the original. I have seen him debugging code in the evenings though. This consisted of printing out the entire programme (in the DBase sense a "programme" is a single file, but a programme in our sense would be a collection of dbase programmes) and the paper (dot matrix, so it's all connected) trailing all thruought the house as he draws pencil lines all over it to reconstruct programme flow. no indentation at all The short answer to your question is no, I didn't see any evidence of improved structure or practices at all. All variables global. goto ftw. no procedures/methods/functions at all. He's never even heard of the concept when I tried to explain. [Edit: managed to get hold of some of the code (see parent) and it looks like I was wrong on the indentation - he did start to use it at some point]
- slurgfest 14y ago
  closely looking at a printout is an underrated archaic practice.
  - ams6110 14y ago
    Ah yes "desk checking." When compiles took hours or would only run during the overnight batch cycle. You better believe it was worth spending some time manually reviewing your code.
- schmrz 14y ago
  I'm not sure if that's scary or awesome. Probably both. Thanks for sharing!
kamaal 14y ago
You find it hard to believe because you are convinced it can't be done other wise. Once you see some one doing it you will believe otherwise.

kamaal 14y ago

This reminds me of a manager of mine who wrote a 10,000 line Perl script. He thought himself how to write Perl in a week. And then started coding. He wrote a script to automate a very tedious testing process so perfectly, we were able to reduce our test team by like 70% and test more precisely than before. It was fully procedural code. And it looked monstrous. Our architect challenged him that it won't workout. He even challenged to rewrite it in Java, but that project never finished. He was never able to ever complete the rewrite. It motivated me to learn Perl. Since then my life has been totally different. I've done mountains of work alone working, hacking during nights. I learned the following things from that episode: 1. First write the program. 2. Write the correct program. 3. Write the program to run fast and efficient(scalability and all that) 4. Beautify the program. But most people never cross 2)- The point is there are tons of people who can do this tasks related to micro optimization. The people who win in a ordinary work environment are ones who know the art of converting ideas to sell able products in the fastest way possible. By the way that manager also wrote database clients in C++ which helped us troubleshoot our in memory databases from remote locations. Again the architect challenged to get it done Java, as before the project never completed :) Its a fact that majority of the software world is hacked and held in existence with tools like Perl and Php. The people who care about artistic elegance are few, they often fail and generally don't matter.

arethuza 14y ago
Isn't your list a variation on the well known list of: - Make it work - Make it right - Make it fast http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
- alexfoo 14y ago
  Depends on whether step 2 is a complete rewrite (in a different language) or further hacking to "make it right". My process tends to be: 1. Make it work - Knock up a prototype (lots of assumptions made and noted, limited error checking, etc) 2. Make it right - By starting from scratch and use what was learned in making the prototype 3. Make it fast(er) - Having a prototype, and trying it at scale, should have already given me an idea of what algorithms/structures to use/avoid in Stage #2 but, obviously, a further optimisation stage will almost always be beneficial. Ideally (if time allows) the prototype is written in a completely different language to the desired target. This is the most important point. Most of the production code I write is C and I tend to do my prototypes in Perl. The helps me for several reasons: a) ADTs (lists, hashes/dictionaries, etc) are just easier/quicker in Perl/python/ruby than in C (I do have my own C library that I reuse for ADTs so it's not as if it's a great chore writing them each time, but ADT instantiation is just easier in Perl/python/ruby than C). b) It's also easier to play around with different algorithms if you can switch between ADTs more easily. c) I can use the prototype stage to continue to learn new languages (it used to just be Perl but has extended to include languages like Python and ruby). This list will keep on growing. d) It prevents me (or the business) stopping at Stage #1 and using the prototype code for production. (This could be even worse if the prototype was written in C.) e) A prototype, being quicker to knock up, means faster to getting it in-front of someone else to look at and give feedback. f) It prevents me just copy-and-pasting chunks of the prototype code as production code so I, hopefully, don't carry over any of the assumptions I'd made in creating the prototype. g) "Knock up a prototype" doesn't mean no design/testing/etc. I usually end up with design notes and some automated black box testing that can be reused in the later stages.

thewarrior 14y ago

I would like to make a few points , This is only possible because your dad is the only one who has to deal with this program and also he only works on this one big complex thing which he knows really well .

cubicle67 14y ago
oh hell yeah, absolutely. This sort of code is not uncommon at all but is pretty much incomprehensible (let alone maintainable) for anyone beyond the original implementer
- Tycho 14y ago
  If one day somebody else does inherit the codebase, are there any tools out there that are designed to help people in that situation? Like something that de-spaghettifies everything?
  - koide 14y ago
    Appropriately, it's a book: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea... Some automatic tools could help (although I doubt thay'll work on DBase III): Static analysis to see what's there, version control to start at the top and log your way through and be able to rollback to a previous working version. But it's at the very least weeks of pain.

ajuc 14y ago

Because understanding exactly what program should do is more important than understanding what are best practices in CS, or how to abstract things. If you can keep all interactions of your app in your head, then it doesn't matter how badly designed the code is. Architecture is only important because it makes it possible to change things without understanding the whole thing. And complete understanding with bad architecture beats good architecture with incomplete understanding.

kamaal 14y ago
>Architecture is only important because it makes it possible to change things without understanding the whole thing. And for that you need to understand the architecture, ofcourse. You always need to understand something_(n-1) to understand something_n, ad infinitum
- ajuc 14y ago
  It's a fractal, yes, but you can do with only understanding your branch in the highest resolution, you don't need all the details of the whole system (if it's well designed).
arethuza 14y ago
I've never seen anything labelled a "best practise" that has had anything to do with what I would call CS.

anabis 14y ago

The version given to me by my professor was: "Think like an amateur. Execute as an expert." Originally by Takeo Kanade. ( http://www.cs.cmu.edu/interviews/kanade/ http://www.cs.cmu.edu/interviews/kanade/ )