Software design refresher

[btiffin]

Old guy favour request:

Ok, nearing 50, been out of school for a long time now. Spent most of my career programming Forth. It set a pretty strong "mindset" for my design and development philosophy. Forth is uber-interactive, and keeps the mind focused very very well. That leads to a design and development methodology of try it, then buy it or chuck it. Iterations go so fast that chuck it is very inexpensive. Forth definitions are also very small, the editor using 1024 bytes of disk per screen. So you learn very quickly to keep things sharp and focused. Testing is also very iterative and focused. Write a word, test a word. Write the next word, test it, then put the two together and test. The editor is Forth, so there is zero mental swapping during edit, compile, test. Leaves room in the brain to get a few things done before the need for the next test iteration.

This methodology has followed me into later and the current phases of my career. But, I'm not a forther anymore. I'm living in POSIX land, (for lack of a better term). Bash, C, C++, Python, REBOL, OpenCOBOL, and the like. My favoured method of write it, test it, write some more, test more doesn't quite cut it anymore. I'm older now and down to about a 7 digit brain. Anything more than 7 things and I can't hold them all in short term memory. I can't do C in "seven things" and find it very productive. Just the mental swap from Editor -> Compiler -> Go is three, that only leaves 4 slots for functional code. And in C, that's like, well, a header declaration, and the skeleton of a function body. Hard to get much done per iteration and feel like it's tested to a quality that I got used to in the Forth domain.

So, my favour request is;

What are the current trends in quality software development education? I'm not looking for "Agile", "Extreme" or the like, and I do "test driven development" out of hand without thinking about it as a by-product of my forther years. I'm looking for "one dude at the keys" trends. And I'm crusty and stuck in my ways, so if I'm supposed to "design each function on paper", well, I'll ignore that advice. The "design on paper" phase is for high level feature requirements and decision making. If that's the advice, I'll continue with the relatively slow, "write a line of C", compile it, test it, write the next line, compile and test. It's slow, yes, but when I'm done I can usually pass the function/feature off to colleagues with a level of confidence that it won't bork on their first or fortieth usage. My method follows up the food chain from low level functions (tested every few (very few) expressions) up to gluing functions into application usage (tested every few "interaction points").

Just curious if there are any new methods being taught that I may not be aware of. And if this request gets a response, perhaps a lively debate to refresh the engines so to speak. Can I be reprogrammed? Are there new methods that let a 7 digit brain do 8 things before making mistakes?

Cheers

Edit: Oh, I'm also asking as I'm about to embark on embedding Guile into the OpenCOBOL distribution and I don't want to be four years getting it done. It'll require mixing the languages and also the libtoolizing of the sources. That there already takes 5 of my 7 slots.

Other edit; board didn't want to take the proper u (from Character map) in uber. It came up as ? mark when I read over the post.

[yoursecretninja]

Not sure what other schools are teaching but when we look at software design it's always a discussion about waterfall.

At work we practice agile. Again, it's team-based though. We have a very small team of just two programmers and a designer so this approach keeps us working together without a lot of overhead.

On my personal projects I used to take a write, compile or run, and then accept or toss approach. I've now starting being a little more rigorous and find I'm more productive. I'll scratch out my idea, write stubs for my classes and methods, and then write tests against them which will fail since the methods aren't implemented. I'll then go back and start filling in my stubs and get my tests to pass. Now I'll compile or run a lot less frequently since I know I'm on the right track if my tests are passing. Now when I run my program it's not really to see if things are working but to see if things feel right in the UI. That works for me, for now. I'm always looking to pick up new tricks though. I'd love to hear how others approach design.

Edit: Just wanted to add, as it's somewhat related, that I use git extensively while I work. When I was hashing out new ideas I used to comment out a lot of code or save alternate versions of things when I was sitting on the fence about whether to keep or toss code or trying to decide the best implementation. Now because I've always got my terminal open and constantly commit I just delete things or change things without worry because I know if I change my mind and want to put it back later I can just grab it from my repo. I find this also forces me to keep my programs in a working state because it's just wrong to commit things that will break a build. It's really quite liberating and it keeps my code and file system a lot cleaner.

[Tony]

yoursecretninja @ Sun Mar 27, 2011 6:00 pm wrote:

always a discussion about waterfall.

http://compsci.ca/blog/educational-flaws-programming-with-the-waterfall-model/

Quote:

The origin of the term "waterfall" is often cited to be an article published in 1970 by W. W. Royce. Royce himself advocated an iterative approach to software development and did not even use the term "waterfall". Royce originally described what is now known as the waterfall model as an example of a method that he argued "is risky and invites failure".

Just to throw a curveball at you guys -- coding by a method of getting drunk and typing like mad. Aka, The Social Network approach -- http://www.youtube.com/watch?v=uxKmDWDUZ5A

@btiffin -- it sounds like the problems might be in the context-switch costs. You can either minimize the number of steps (e.g. interpreted languages don't require compilations, or build scripts (such as Make) that automate repetitive tasks), or just don't them less often (don't _really_ need to compile after every new line of code.

[btiffin]

Yeah Tony, I think it is mostly the context switching that is slowing down (my) development.

Where is the Forth console for the C ABI?

Cheers