[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 28/04/14 09:33, Philip Hudson wrote:
I cant argue with that - what you are experience here is Dilbert space! I think we are singing from the same song sheet in many respects! I tend to come from the point of view that if you don't understand a problem space you are never going to be able to code it and its NEVER going to be simpler than the real problem. The fact that while coding certain problems you, as an experienced programmer, will actually simplify many seemingly complicated problems (and realise that most management are ignorant chancers who hate being caught out) doesn't change the fact that to solve an problem that requires n variable for a solution will never properly be solved by using n-1 even it that does give the illusion of working some of the time. The trouble is the earlier mentioned management will jump on the n-1 solution if they can blame you for it when it goes wrong. But that doesn't make the real solution easier. Good programming can make it look better (to a programmer) but it doesn't make it simpler - your experienced analysis may but that's because the problem was not as specc'ed.On 28 April 2014 02:16, Simon Waters <simon@xxxxxxxxxxxxxx> wrote:difficult problems don't demand big solutions.The claim I'm disputing is that the solutions are necessarily and inevitably "complicated [and] long-winded". "Big" does not necessarily imply either of those. But yes, as the examples you give show, "big" is not always necessary in a solution either. Programming is all about managing complexity. Bad programmers write complicated, long-winded code even for relatively simple problem domains and never learn any other way. They don't try to learn any other way, they are not interested in learning any other way; they complacently assume utterly false estimations of their own ability and code quality and seek out peers who will reflect and reinforce those false estimations. Unfortunately, it is not only possible but hideously common for such programmers to have long, successful and lucrative careers, infecting every code base they touch with insurmountable cruft and technical debt, thanks to the near-ubiquity in industry of ignorant, incompetent and negligent development managers whose only benchmark of programmer success is the number of lines of code written, regardless of need or quality. The result is plain to see: software sucks. There are *many* efficacious tools and techniques for attacking this problem. Good programmers seek them out, learn them, apply them and share them. Faced with big, complicated problems, good programmers produce solutions which are elegant, learnable, maintainable, flexible, robust, and, yes, simple, at any particular layer or granularity -- they know how to segment. Perhaps most importantly, good programmers produce code that is *tractable*, meaning the code is amenable to being reasoned about. Unfortunately, since deploying those techniques often leads to not just fewer lines of code produced per programmer per unit time, but to actual net negative line counts as cruft is removed and consolidated, programmers who deploy them effectively are not valued by (incompetent, remember) management; and since, properly understood, the work they do demonstrates that most of the programming work that is currently being done, and thus most of the headcount doing it, is pure waste, good programmers are also seen as a threat by the feather-bedded incumbent corps, who work to get them ousted ASAP. I don't mean to come across as bitter and resentful, but I am, so it shows.
Tom te tom te tom -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq