Helpers Vs. Hurters

Replies are listed 'Best First'.
Re: Helpers Vs. Hurters by pboin (Deacon) on Nov 17, 2005 at 12:00 UTC
Well, you really have answered your own question. You must find the sweet-spot. Let's start with one end of the continuum: no 'helper' routines. We all should agreee that that's just not a good idea. To a certain extent all functions fit this definition. Sometimes they're tiny, and sometimes they're complex, but any time you call another piece of code, you're reusing it, and the programmer calling it might not understand how it works. Sometimes that's OK. I use stuff from CPAN that I don't understand, but to a certain extent, that's the point. I don't have to understand, I don't need to understand, I don't even want to understand. At the other end we have the old cargo cult phenomenon. It's real easy to be bad-lazy and reuse code in the wrong way, or in a very inefficient way. I think this is where experience is important. A senior programmer can look over a juniors work and make sure that they're not drifting too far into the weeds and at the same time, they understand the pertinent parts of the project. I work alone, and this lack of peer review (formal and informal both) is without a doubt the single largest drag on my effectiveness and productivity. So, good luck, and make sure to have seniors and juniors working together.	[reply]
Re^2: Helpers Vs. Hurters by BrowserUk (Patriarch) on Nov 17, 2005 at 12:09 UTC
I work alone, and this lack of peer review ... is without a doubt the single largest drag on my effectiveness and productivity. Ain't that the truth. ++ Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l]
Re: Helpers Vs. Hurters by philcrow (Priest) on Nov 17, 2005 at 14:33 UTC
If the routines are good and well documented, I refuse to worry about whether new programmers will lean on them. Consider a few examples: We shouldn't include hashes as a primative type or no one will know how to implement one for themselves. We shouldn't use DBI or no one will know the API of our database first hand. Perhaps you can see where I'm headed. Over time, we tend to raise the level of our efforts. This leads to current complaints like: If we use a data modeler like Class::DBI (or one of its cousins) no one will know sql. There are three groups of people after such a shift: The ones who are able to work on the abstraction. The ones who can use the underlying tool without the abstraction, but don't understand the magic of the abstraction itself. The ones who rely on the abstraction. Whether anyone needs to be in the second group is really what the debate is about. I would argue that if the abstraction is useful enough and the implementation of it is documented well enough, it doesn't matter whether anyone is currently in group 2. Smart people will be able to migrate through group 2 and into group 1 when the need arises. This discussion reminds me of the original Star Trek where Gene Rodenberry (probably misspelled) worried several times about societies which developed such successful technology that generations went by when no one needed to work on it. Then, inevitably, it began to fail and the society was on the brink of dying out because no one could fix it. That plot is not particularly compelling to me. No technology gets to that point unless it is no longer used. As long as someone in your shop is maintaining your abstractions, work on them can continue. If they are internally documented, others will be able to step in when the maintainers leave the company. In the mean time, everyone else works much faster. If the Perl community suddenly needed me to step up as the maintainer of hashes, I would have a lot of catching up to do. Similarly, colleagues would have some catching up to do, if they suddenly needed to work on the abstractions I maintain in our shop. I don't seem to loose much sleep over either of these situations. Mean while the abstractions in question save a lot of time. Phil	[reply]
Re: Helpers Vs. Hurters by samizdat (Vicar) on Nov 17, 2005 at 13:57 UTC
I have found that there are three classes of site-specific libraries that get developed. Kitchen Sink Utility Libraries Chunk Libraries Interface Libraries Yes, you can chalk it all up to 'good documentation'. :D Seriously, the only ones that I see getting out of hand are the KSL group, because they really have no cohesive purpose. Chunk and Interface Libraries do have such a cohesion and are constrained by their functional purpose and API, respectively. I tried once to separate out KS functionality, much as C does with its #includes, but the only way that worked was when I enforced use of a program template that had them all pre-embedded. Until I did that, everybody quickly made `use KitchenSink;` which was itself a bunch of `use foo;` calls. Perl programmers ARE lazy (otherwise we'd all be J^v^ or C++ coders), but that's part of the reason why we're GOOD. The point has been made that the goal is to develop a large application. Coders of any stripe DO need to concentrate their attention, and it is rare that concentrating on the meta-hierarchy can be sustained even by the best of us. Some coders are better at that than others, and I think you need to accept that completing your project will require identifying the few that can hold multilevel system analyses in their head and giving them the task of maintaining the libraries. This is generally a burst-mode activity and you need to make your managers understand that these guys are working hard -- or recovering from such -- when they're staring off into space. Those that aren't comfortable with this can also be good and productive coders, but you need to keep them focused on one level where their linear thinking and planar grasp of relationships can be applied effectively. So, to summarize: document thoroughly, divide up your tasking to maximize people effectiveness, and explain this last to your management well.	[reply] [d/l] [select]
Re: Helpers Vs. Hurters by blue_cowdawg (Monsignor) on Nov 17, 2005 at 14:29 UTC
FWIW I'll chime in with my US$0.02 worth.... How far can you go with these helper functions before they hurt more than help? The answer is: it depends. I've seen some extremes here in my travels about the industry. In one shop I worked in my job was to take the code that "low talent" programmers wrote and make it actually work. They had lots of helper code out there to help them to the point that all they really needed to do was cut/paste and put in some glue code to produce a working application. In spite of that they failed to produce working code about half the time and code that behaved in expected ways about 60% of the time and nearly all if it had bugs and/or security holes big enough to drive an SUV through. Another shop I worked in had their data objects, stored procedures and such all well defined in an API such that writing code there from inception to working prototype had a very short time frame. Given the business environment this gave the company a very huge competitive edge that they leveraged off of every chance they got. Yet another shop it was every person for themselves and each developer had a piece of the project and worked on it independantly with no one person driving the overall design. The term "1000 monkeys with typewriters attempting to produce Shakespere" used to run through my mind there constantly. As can be expected they had issues itegrating the individual modules that each developer was developing independantly from the other and getting the end (?) product to work. So... the official answer is: it depends. Whatever helper functions get developed need to fit within an overall architecture and need to be well documented. How can you keep your developers on the ball in using these functions and in keeping the functions up-to-date? Can you simply chalk this up to 'make good documentation'? Code specifications, having an overall code architect that sets direction, peer review and taking care to develop helper functions that are well documented, flexible, can be extended without modifying the "original" and taking care not to go too overboard that you squelch creativity as well as flexibility in your development environment. On the other hand, what is a good marker for what should be in helper functions and what belongs in tighter control and usage? See above. I have worked places where there was too much rigidity to the point where I had to get all sorts of sign offs and go through bureaucratic hoops to introduce a new Perl module either from CPAN or of my own authorship to places where it was total anarchy. Neither extreme makes sense. Finding the "sweet spot" requires effort up front and constant review and an occasional reality check to make sure your not going too far or being too lax. Peter L. Berghold -- Unix Professional Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg	[reply]
Re: Helpers Vs. Hurters by hakkr (Chaplain) on Nov 17, 2005 at 12:05 UTC
Interesting viewpoint, A coder can only really be expected to understand and manage a finite number of lines of code. So having abstracted the Programmer interfaces, which your helper functions really are will definitly help to limit your universe of code. As you point out this is espcially useful if the underlying implementation is some low level black magic that nobody needs to worry about. So generally if your helper functions relate to 3rd party libraries that you will not or cannot modify then you are ok. For example I use many cpan modules and am lazy in that I have no clue how most of them work under the hood. If I tried to understand them all my brain would surely explode. Now if I did have a problem or want to extend a cpan module I would check out the documentation/POD for it and speak to my colleagues, failing them then the author. The same applies to you internally make sure these utility modules are well documented so that any coder can look into them. As for what is in the modules it is a case of the level of control required and the amount/quality of each api exposed. Consider for your business and your programmers skill set which parts of the code are most important, sounds like you work with xml so maybe ensure all you coders know the basics of cpan xml modules	[reply]
Re: Helpers Vs. Hurters by pajout (Curate) on Nov 17, 2005 at 13:04 UTC
You explained my ideas :)) I discuss it with my boss sometimes, I say 'they will share code' and he say 'they will use black boxes'. My arguments are start-quickness of new coders, code sharing, work effectivity (ideally, no wheel reinvention), less amount of code. His arguments are laziness, black boxes, impossibility of usefull interface design and the potentiality that nobody will be able to hack old, heavily shared libraries/modules. But I think that good documentation and voluntary on-the-job training can boost my arguments.	[reply]
Re: Helpers Vs. Hurters by Aristotle (Chancellor) on Nov 18, 2005 at 14:32 UTC
From MJD’s file of good advice: `#11911 You wrote the same thing twice here. The cardinal rule of programming is that you never ever write the same thing twice.` It’s madness to build and maintain large systems with “snippet copy&paste” programming. Think about it: Perl itself is a large helping of “helper functions” draped over C, no? I don’t think anyone would argue that you should use C, lest you forget how to manage memory manually. The question depends mostly on how well-designed your helper functions are. They need to be either simple or complex enough that you can either forgo them or use them, but never need to work around them. Finding the right granularity of separation of concerns is of the essence. Makeshifts last the longest.	[reply]


Perl Monk, Perl Meditation
	PerlMonks