''Have you ever been surprised at how simple complexity is? -- DaveHarris'' Yes, and no. I'm often delighted when something seemingly complex falls into place in simple form. Taken unawares by the specific simple solution, but not surprised by the fact that it can be found. Almost always it's there to be discovered, reducing some bizarre and complex algorithm to something straightforward. Except, sometimes, in the works of man (see DijkstraAndRefrigerators). In the payroll system that was the subject of this aborted page, we've found man-made complexity that won't simplify. Totally arbitrary decisions that make as much sense as multiplying the date times the pay rate and storing the result, to save space. Fields given new values but not new names. Five guys with different union dues from anyone else. Still, there's even a simple way to reflect those strange factors ... you just have to find it. Here's a question, to quote the famous AnnAnderson: Can you always ''refactor'' from complexity to simplicity, or is it sometimes necessary to make a leap? --RonJeffries I'm usually more surprised by how complex simplicity is. - Alistair When you're a bear of very little brain, you have to assume there's simplicity to be found, lest you continue to bump downstairs on your head. - Ron Oh. That may explain this constant pounding between my ears... wonder how I turn the other way up. Sounds simple enough... - Alistair I'm a bear with a very little brain, and what I find is that when I'm faced with solving a problem I'll first "solve it" by specifying code that's complex and prone for defects. Then, through the fact that I became more intimate with the problem I'm trying to solve by doing it, I'll start refactoring. I do this out of reaction because I learn new things and have new insights about the problem that help me make solving it simpler, in a Darwinistic sense. Finally, in the end, when I'm satisfied with its simplicity, if people decide they want to criticize me for it, I can start firing questions at them that start showing them why it's that way. So yes I have a little brain, and it throbs a lot. Perhaps I'm a masochist. But I like making it simple and I like it when I find people who can prove me wrong. - Philip ----- What I meant is that a complex thing is made out of a large number of different pieces that interact. The pieces themselves don't have to be complex. The original Payroll page looked like that - lots of pieces none of which seem too bad on their own. The description looked simple because complexity can be simple, even though it is still complex in another sense. The killer is the "that interact" part. The first step towards simplifying may not be to identify commonalities and refactor, but to isolate into chunks that interact as little as possible. It's OK to have 5 guys with different union dues if their special rules can be isolated. I guess to really get the complexity across you need to explain how hard the isolation is/was to do. -- DaveHarris ''"I'm sorry, Dave, I can't do that." (I always wanted to say that.) I've solved very few complex problems. Did a couple of operating systems, but they weren't very complex ... the relational database systems we wrote were pretty simple ... optimizing FORTRAN wasn't very tricky. There was this Extended Memory allocator for a set-theoretic database for the PC that my partner couldn't get debugged. We rewrote that so it was simple enough to see that it worked. Nope, sorry, I can't describe anything complex that I ever managed to do. --RonJeffries'' Me too. Simply right, simply wrong or complexly meaningless. --RichardDrake So is payroll easy after all, or is it hard in some way not involving complexity? -- DaveHarris WhyIsPayrollHard I guess the point of this page is that nearly anything, no matter how apparently complex, can be ''implemented'' simply. And that starting with simple solutions can carry the day quite well. As for payroll as a problem, the requirements are hard and often surprisingly complex. I'd say it's harder than a language compiler, harder but smaller than a relational database system. Our implementation is [mostly] simple and straightforward. Getting it simple is usually a matter of starting simple, but it's hard for smart people not to do clever things sometimes. The surprising result, to me, was that in watching it we realized how seldom the cleverness pays off, and how often it gets in the way of necessary change later. --RonJeffries I can't recall the Einstein or Ingalls quotes, but perhaps the real goal is to conceptually simple solutions to problems that (at first sight) appear intrinsically complex and difficult --- iteratively designing solutions which are ''just complex enough'' to satisfy the underlying problems. This is very different to common practice PeterPrincipleProgramming --- making the most complex thing that just sort of works, for example writing the two hundred vendor required lines of code to create a window, and another hundred to display it. DoTheSimplestThingThatCouldPossiblyWork is very different from DoTheEasiestThingThatCouldPossiblyWork (see also the ProgrammersStone) -- TheResidentCynic I think "the Einstein quote" would be (approximately - please correct) ''Everything should be made as simple as possible - but no simpler''. There's also a related quote from was TonyHoare: ''There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.'' ---- Everything is made of simple parts when EverythingIsa ---- CategoryComplexity