Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Pastimes : Dream Machine ( Build your own PC ) -- Ignore unavailable to you. Want to Upgrade?

To: Sean W. Smith who wrote (3416)	11/5/1998 3:38:00 PM
From: pae	Read Replies (2) \| Respond to of 14778

Just another opionion.... Sean Interesting opinion! Never thought of KISS as repressive - more as a philosophy to keep me out of the ditch and to avoid fixing things twice. Of course I've done a lot of technical cleanup - I've swept up, fixed, repaired, redesigned and re-coded so many things built by those who forgot about existing barriers and the obvious that my personal appreciation for KISS may be over-developed. The entrepreneurial technical visionaries do have a hugely important role to play in developing the bleeding edge of new technology … but I've seen their code. From the inside. And it was NOT robust. <vbg> While the visionaries were and are no doubt convinced of the righteousness of their output (theirs didn't stink either), a certain element of today and reality is highly recommended for those of us dealing with due dates, deadlines, blue screens of death and other existing barriers. I believe the easy road offers many advantages to the ditch. The ability to see beyond the current problem and avoid future problems has value, whereas I doubt that "newness" has value in and of itelf - unless your industry is fashion. Note that we still employ the wheel, although it has the disadvantage of being a "used" rather than a new concept. Indeed, simplicity is MORE robust than "solutions" unfettered by the bounds of space and time. More complicated and further reaching are not necessarily better, and are undeniably more prone to crashing and burning. A hand crank window that works is infinitely superior to an electric window that doesn't. My concept of KISS doesn't include keeping the system on paper due to distrust of electronics: once a system exceeds a certain size or number of users - electronics rule. But I'm not convinced that I need a wireless link to my pantry and a bar code reader to manage my grocery list. I know I could NEVER get the boss to update inventory anyway. <g> My point is that persons using KISS as a tool of repression likely have other tools to use toward the same effect. The tools are not to blame for the user's bad behavior. I don't blame my circular saw for a bad cut - I know I can cut the board a second time with my hand saw (less technology) and it will STILL be too short. <g> I wouldn't blame KISS, complexity, or technology. While I might check my tape measure, I would blame he who made the measurement and drew the mark: me. I doubt a laser saw would cure my ability to read a tape measure. A laser range-finder might. Let's not neglect the other extreme of technologic behavior: the technician-control-freak who carves an empire for himself by making every task impenetrably dense and refusing to work through details with the team - thereby creating a zone of things that only Bill can do. Bill views others not seeing it Bill's way as limited and unworthy of explanation. (If they don't already understand it, they don't deserve an explanation.) In such cases, perhaps repression is warranted! Certainly KISS is warranted. And a manager or team that would allow such chaos to continue would be as negligent as the technician-control-freak. But in this case I would strive to NOT blame technology for Bill's bad behavior. I would fault Bill, Bill's management and Bill's team for allowing this behavior to continue. My use of the KISS tool (concept) is as a construct to be used to avoid technical overkill. The bridge too far is costly in time, effort and dollars. It is counter-productive. I try to recognize that bridge and NOT go for it. Now if we could just get all the technician-control-freak empire builders to work for the repressive managers, the rest of us could sit back and let them be counter-productive w/o affecting those of us so productive as to have read so far down in such an obviously over-cooked post! <g> With just the right amount of technology, of course. Just my less than humble, but intended as humorous, opinion. Paul

To: Sean W. Smith who wrote (3416)	11/5/1998 8:08:00 PM
From: Spots	Read Replies (1) \| Respond to of 14778

>>[On KISS] I use this principal sometimes but try to avoid it and always look past the obvious forgetting about any existing barriers in your way Just exactly so. I find it used this way too, most often. And yet, I rework software almost beyond measure trying to simplify it, and after a while, by gum, even the most difficult problems usually end up with a simpler solution (algorithmically sometimes, but most often just implementation). To put it another way, which I think is really what you're getting at, simplicity takes a hell of a lot of work. On the other hand, if you're approaching something you're just beginning to understand, keeping it simple and direct upfront saves you from a lot of useless work which will be thrown away after some experience, when you understand it better. I think this is the sense in which Paul is using the term, despite his unfortunate reference to software design. It has taken me many, many years to learn this (ok, I'm a slow learner), and I STILL err on the side of analyzing too early, before I know enough to do an efficient analysis. Throw most of it out and could have done it better with a few more mistakes under my belt. KISS works for this. Sad to say, the distinction is very difficult to make. Of course, this is called a "top down" approach in the jargon, but it's not simple to use the discipline effectively. To broach an old subject a bit, since I've laid down all this groundwork <g>, I find a VERY great deal of popular project management, software "quality" methodology, and similar hot software topics very much in this category. I specifically include structured walkthroughs, code reviews, etc. I have seen them work, BTW, but far (far far) more often, they are reviews of ill-understood problems by people ill-prepared to judge what they are reviewing based on the ill-considered notion you can anticipate end results with a "careful" design. May I never ever hear the term "careful design" again from anyone who can dictate my activities ... Sorry, an over-lengthy aside on an ancient topic. Spots