From You Are Not a Gadget:
Little programs are delightful to write in isolation, but the process of maintaining large-scale software is always miserable. … Technologists wish every program behaved like a brand-new, playful little program, and will use any available psychological strategy to avoid thinking about computers realistically.
Ain’t that the truth.
Actually, I like embarking on large projects for personal projects, because I see it as an opportunity to learn more about available tools past just programming languages. The programming language you select is often inconsequential compared to having the right tool chain to go with it.
I admire people like Michael Feathers and John Robbins who enjoy digging into large legacy projects, but that’s not how I prefer to earn a living.
Big programs are interesting. Programmers learn to to think about programs in terms of small quantities (lines of code, classes, etc). This comes from Universities where too much emphasis is put in computer science (syntax and algorithmic view).
Big system are complex beasts, you can’t use the programmer view. You need to identity structures in terms of cohesion, coupling, contracts, components, etc. You need to see beyond code. Wish Universities understands this.
Omar,
I took a second year course in SE last year that, amongst other things, covered cohesion, coupling, components etc.
It was quite interesting.
“UNIX is lots of little programs connected by shell scripts, Java is big programs connected by XML” – Stuart Sierra
Big programs, poorly architected are a nightmare. But big programs, well architected are a pleasure. And when you find–or design–the latter, more often than not, you’ll find a big program that is really a federation of many small programs (or services), each of which does something very specific and very well.
In APL, even programs that do many things do not have to be big. APL programs are as big as the problem they are solving, i.e. they have a length of 1 problem.
TO paraphrase another Randy, “Big programs have no reason to live.”
kx.com’s products are a counter-example.
tiny, tiny programs.
big, big data (multi-gigabyte to terabyte)
They mostly deal with the needs of wall street, and they have people buying their software at with a cost of several cents for each byte of code, because those bytes are so well chosen.
So, with example in mind, I think the reason we do not use small programs might be because we do not want to pay for them.
Writing a good small program is harder than writing a good big program. But sometimes it’s worthwhile: By reducing how much code needs to be executed, the code runs faster. It’s not just that fewer instructions need to be executed, but code that fits in a cpu cache can have an order of magnitude speed advantage over code which does not fit.
This ideal especially for working with big systems. If i design a software system i would prefer the classes to be small especially if you think about maintenance. With maintenance you also have to think of the fact that not everyone writes good code. A bad programmer writing bad code over a long class would be totally difficult to work with if you are in a team environment. Another point is that im my opinion i think a properly designed software system does without the big classes isn’t this one of the goals of object oriented design? Functionality is separated and put in appropriate classes which model real world entities?