Re^5: improving the aesthetics of perl code

The overweight cat was feeling drowsy having eaten a large meal, and lay down on the mat to sleep.

Concise, joined up, complete.

And yet, your re-factoring of this very simple story contains several subtle flaws. First of all, "overweight" generally implies someone who is thinner than someone who is "fat". Someone who is "drowsy" is just on the threshold of becoming "sleepy". In the original story, the cat sits on the mat: it doesn't lie on it. In the refactored version, the meal is correlated with sleepiness: in the original, direct causation is explictly spelled out.

If some zoologist spent months coming to the conclusion of causation, it's a serious loss of domain knowledge to downgrade the information back to mere correlation. Similary, if overweight cats sit rather than lie, it may imply something important to future zoological researchers. As you point out, it can be tricky to manage code: the K.I.S.S. principle of engineering should apply wherever possible.

Software constitutes some of the most complex creations of man. Writing software is one of the most challenging endevours man undertakes,

I disagree. There are several domains far more rich and complex than computer programming, and yet we manage complexity in them on a regular basis. Physics is nothing less than the formal study of the entire physical universe. Modern medicine is the study of how to maintain over six billion uniquely distinct lifeforms in working order, each one of which is a composite of a myriad different kinds of sub-lifeforms, and miniature ecosystems. Computer Science is the formal study of algorithms, including both their design, and formal proofs of correctness. It's only a tiny subset of the vast, mind-boggling complexity of mathematics. Non-commutative algebra is complex. Quantum mechanics is complex. Computer Science is complex. Computer programming, especially as applied to typical business purposes, is not so complex.

Programming is largely just a matter of encoding: translating known algorithms into existing computer languages to solve real world business problems.

and requires education, skills and experience to do well.

This is true of almost any discipline, from basketweaving to automotive repair. It's a bad idea to trivialize any form of learning.

You would not employ a lawnmower service apprentice to work on your Lexus or Mercedes.

I most certainly would. If a "lawnmower service apprentice" (or any other unskilled person, for that matter) can't re-fuel the vehicle, check the oil, top up the fluids, or change a tire, then the car design is too complex.

If a "semi-skilled" automobile mechanic can't repair the car, the design is also flawed. Remember, mechanics are maintenance workers: they're not all formally trained automotive design engineers. They don't need to be. I doubt either my cousin or my uncle could calculate the stopping distance of my car based upon the co-efficient of friction of the brake pads and the related engineering equations: but they certainly know how and when to replace them. That's because automotive design engineers deliberately take maintenance into account: they make parts easy to replace, they provide "dumbed down" (i.e. "useful") replacement part and part substitution tables, and they document everything at a level the mechanics can understand. They specifically don't assume they're writing for someone with an engineering background.

Or a flight attendant to fly your 767. Modern airplanes are so well engineered that they almost fly themselves. A flight attendant with minimal training (or more likely, minimal coaching from the control tower), could active the automatic landing systems in an emergency. That's because the systems are well designed, and simple.

Pilots hate complexity. The main goal of running an airline is to force the pilot to think as little as possible. I know, because I worked for the airline industry for 2.5 years, providing data for the pilots to take off and land. The goal was always to make everything as consistant and obvious as possible, because every time a pilot has to make a decision, there's a small chance he'll make the wrong decision. If he doesn't have to plan, he can focus all his attention on making his execution perfect.

Nor a med. student to perform open heart surgery.

Nurses, not doctors, take blood pressure, throat swabs, and perform other mundane operations. My family doctor doesn't have the skills of a heart surgeon, but he's certainly not useless. In medicine, again, a tiered approach manages complexity in a cost effective way. If everyone in the hospital absolutely had to be a surgeon, because "medicine is complicated", then we could only afford one or two hospitals per country. There would be surgeons sweeping the floors. It would be a pointless waste of talent.

Why would you employ a 14 y/o to edit anything important? Why not? If the work is within their level of competency, then it's cost effective to hire them, since they tend to work for lower wages. Sound business practices dictate that I should hire the person who will do the required job, for the lowest wages. I don't care how smart my janitor is; I just need clean bathrooms.

Equally, employing unskilled, or semi-skilled persons to maintain your business software, and deskilling your programmers to write baby code in order that you can, is stupid and counter productive.

I disagree completely. I've shown that there are tiers of competency throughout the rest of industry, for reasons for cost-effectiveness, and maximizing the productivity of the true experts. I see no reason why programming should be different, here.

After all, aren't all computer programmers in some sense just "semi-skilled" computer engineers: unaware of all the electronic complexities of the circuitry and hardware that they operate? Call it "dumbing down" if you like, but the more common term is "abstraction", and it lies at the heart of how we manage complexity, both within and outside our field.

The term "baby code" is just plain perjorative: all code must still meet its full business requirements, or it's useless. Code that fills the required business need, and is easy to maintain is correct code. Anything else is not.

It's not "de-skilling" a programmer to teach him to express himself clearly. After all, programming is almost entirely about clear, unambiguous specification of requirements: both to the machine, so that work is carried out correctly, and to fellow programmers, so that the specifications are obvious and easy to modify.

If you dumb down the code, the maintenance programmer will never aquire better skills.

I disagree. Training programs for staff should not be carried out on mission critical systems.

Supervise their work and train them. If I have to pay a senior programmer to supervise each line of code a junior programmer writes, it's equivalent to paying the senior programmer to write it for me. The senior programmer is still doing the real work: the maintenance programmer is being trained for free on company time. Mentoring may be one useful form of training, but it's certainly not the only kind, nor is it guaranteed to be the most effective. The rewards will outweight the costs. That's not necessarily true. Could I have hired a more skilled programmer for the cost of free training I'm offering the maintenance programmer? Could I have taught him the equivalent skills in some other way for less money? If so, then I'm wasting time and money bringing him up to speed by mentoring him.

And if I can teach my senior programmers to write clearly in the first place, 90% of the time I'll be able to let my junior coder just fix things. 10% of the time, he'll have to call in someone more senior to explain things, but the cost savings are obvious. I'm not paying the surgeon to watch the janitor sweep the floors.

No one needs to know that you passed grade 13 English with a 97% average"

Then why is your highest priority item?

"As others have mentioned, spelling and grammer are very important. Learn to express yourself in English, first."

There's no contradiction: good spelling and grammar are very important. Unfortunately, deliberately using a complex vocabulary will often give you good marks in high school English. However, you'll still fail any technical writing course you take, if your vocabulary choices confuse your target audience. Computer code and comments are a form of technical writing: it's not about creative personal expression, except perhaps for code written at home for fun. In the business world, confusion costs money.

To further clarify: people should know that you're fluent in English, or rather, it should never become obvious to the reader that you're not. And they certainly shouldn't have to suffer through a pompous display of unnecessary vocabulary to just to understand your comments, or your code.
--
Ytrew

Comment on Re^5: improving the aesthetics of perl code

Replies are listed 'Best First'.
Re^6: improving the aesthetics of perl code by hv (Prior) on Jan 24, 2005 at 14:19 UTC
And if I can teach my senior programmers to write clearly in the first place, 90% of the time I'll be able to let my junior coder just fix things. 10% of the time, he'll have to call in someone more senior to explain things ... The tricky bit is determining whether the junior coder can recognise the 10% he can't fix himself. Hugo	[reply]
Re^7: improving the aesthetics of perl code by Ytrew (Pilgrim) on Jan 26, 2005 at 07:36 UTC
The tricky bit is determining whether the junior coder can recognise the 10% he can't fix himself. Actually, the hardest task is probably correctly assigning the junior programmer to tasks which he's likely to be able to accomplish, and watching him carefully when it doubt. :-) But this job can be made easier by documentation. Part of the documentation job that the senior programmers need to do is clearly explain where that complicated 10% of the codebase lies, and what level audience each section of it was written for. Good documentation and testing techniques should also tie business requirements to specific sections of the codebase, if only for verification purposes. ("Yes, the billing section works!"). The major and minor business premises and code specific assumptions should also be documented in case of change. From that documentation, it's much easier to see who can work on which sections of code. First of all, if the code was written for a more advanced background than a programmer has, he doesn't get assigned to it. If the new business requirements don't challenge any of the assumptions, then the new code can be slotted directly in for the old. If the novice can write the code, then he can do the maintenance. If some of the lesser assumptions of the code have changed, minor re-design may be needed. With some guidance and direction from a design architect, the problem can probably be delegated to an intermediate progammer. If some of the major assumptions about the code have changed, then it will probably take some serious design work on the part of the senior architect, and possibly be delegated to the senior programmers to work on. If all of the major assumptions about the code have changed, it may be time to write a new codebase. ;-) -- Ytrew	[reply]
Re^6: improving the aesthetics of perl code by Anonymous Monk on Jan 24, 2005 at 14:57 UTC
"After all, aren't all computer programmers in some sense just "semi-skilled" computer engineers:" That one sentence betrays the source on much of your misunderstanding. So much so, that countering many of your other statements is pointless in it's light. If you believe that programming is "semi-skilled", and a branch of electronic engineering, it is easy to see how you can equate software maintenance with re-fueling a vehicle or topping up the fluids. That type of vehicle maintenance is to do with replacement of consumables. Software has no equivalent unless you are going to suggest that putting a new writable CD in the drive or paper in the printer is a "software mainenance" task? Software maintenance is more akin to re-engineering the suspension when it fails to meet the ride or handling characteristics required; or altering the fuel/air mixture to compensate for high altitude use. To be able to perform this type of maintenance requires the maintainer to have a full understanding of the principles that underly the original design in order that they can re-engineer the appropriate components to compensate for the inadaquacies. The role of software mainenance often requires greater skills than the original programmer, because an underlying principle of software mainenance is that of "least change". Often the easiest way to correct a bug would be to re-write a large swath of code surrounding it. Doing so entails huge risk, because of knock-on effects, and huge cost, because the larger the scope of the change, the more re-testing and proving requires. The single biggest source of errors and unnecessary costs in software are those that come about as a result of viewing the mainenance role as a second fiddle, lesser skill. It isn't.	[reply]
Re^7: improving the aesthetics of perl code by Ytrew (Pilgrim) on Jan 26, 2005 at 06:47 UTC
That one sentence betrays the source on much of your misunderstanding. So much so, that countering many of your other statements is pointless in it's light. You've progressed successively from sarcasm, through elitism to ad homiem attack. I was trying to be nice, and give you the benefit of the doubt, but I strongly suspect you're trolling now. In any event, I'm getting tired of this debate: this will be my last reply. If you believe that programming is "semi-skilled", and a branch of electronic engineering, First of all, "semi-skilled" was the term that you had used to denigrate the skillsets of certain non-programmers. I deliberately put the words in quotes because I was quoting you, and because I wanted to demonstrate to you how that view was as unfair. If you really don't like the term, feel free to stop using it. No, I don't believe programmers are semi-skilled: any more than I believe that anyone else is "semi-skilled". I object to the term itself as categorization as excessively perjorative and largely unhelpful. Most people posses a wide range of different skills at different levels in different areas. No one is good at everything. As for the second half of your objection, I stand by my claim on the basis of elementary formal logic. Creating an electronic computer, and configuring it to perform a given task by encoding a computer program is by definition electronic engineering: it's engineering an electronic device that produces the desired results, given the desired inputs. The configuration half is clearly a subset of whole process: this act of configuration if called programming. So, yes, both I and basic formal logic both agree that programming is a subset of electronic engineering. It's hardly an abstract statement of faith. Software has no equivalent unless you are going to suggest that putting a new writable CD in the drive or paper in the printer is a "software mainenance" task? Compiling a kernel is a software maintenance task. Editing a configuration file is a very simple software maintenance task, that a very minimally trained person can do. This is akin in my mind to topping up fluids or other acts of simple maintenance. Like other disciplines, there's a clearly a continuum of skill sets here. Contrast "Stewardess, Pilot, Aircraft Engineer" with "Secretary, Sysadmin, Operating Systems Programmer", and note the similarities. Software maintenance is more akin to re-engineering the suspension when it fails to meet the ride or handling characteristics required; or altering the fuel/air mixture to compensate for high altitude use. This is sometimes true. Quite often, however, it is not. Sometimes it is very much akin to routine maintenance. Solving the Y2038 "bug" is an example of routine operating system maintenance. To be able to perform this type of maintenance requires the maintainer to have a full understanding of the principles that underly the original design in order that they can re-engineer the appropriate components to compensate for the inadaquacies. I disagree. The individual assigned to code maintenance doesn't need to understand all of the original design. He just needs to know how his code change fits in. The senior software architect can tell if new business requirements will contradict any of the fundamental design principles of the original design: because he documented them carefully when the code was written. And if that senior design architect has designed a good, simple, modular system, and documented properly, he will know which changes to which sections of code can and can't be assigned to a junior coder, an intermidate, or a senior coder, and the degree of re-engineering required. You don't need a Ph.D. to edit a configuration file, to recompile a kernel, or to uncomment a #define setting in a header file. You don't need a master's degree to write a simple test script to measure return values against a series of constants. The project manager's job is to assign the right person to the right job. The senior architect (and/or senior programmers') job is to give the proect manager enough information about the codebase to make that decision correctly. (If the project manager is a senior programmer, his job is often a lot easier). The role of software mainenance often requires greater skills than the original programmer, because an underlying principle of software mainenance is that of "least change". The principle of "least change" is a vehicle for the real requirement of code correctness. Simple, verifyable code is not only easier to prove correct, it usually includes less interdependancies than more complex code, and hence, fewer changes during maintenance. The principle of least change tends to support simpler code, not more complicated expressions. I maintain my belief in simple, provably correct code. Don't just take my word for it, though. Go and ask experienced programmers who program mission-critical systems (the kind where lives depend on code correctness), what they think of simple systems, and what they think of complex ones. Ask what their opinion of "baby code" that just happens to work, as opposed to any more complicated form of expression. Ask them how important proper documentation, and proper process is to them. Ask them if they maintain tiers of development and maintenance staff. Listen to what they say. Then get back to me. Often the easiest way to correct a bug would be to re-write a large swath of code surrounding it. Doing so entails huge risk, because of knock-on effects, and huge cost, because the larger the scope of the change, the more re-testing and proving requires. This is less likely if the code-base is not a rat's nest of brittle, self-referential, "clever" algorithms, coded just to appease ego. Sorry, but I've seen too many of those lately. Consider a system that encodes a finite state machine for no apparent purpose other than an obfuscated codebase. (If were an actual language to match the automata, and if that language were well documented, and useful for some (any!) programming related purpose, I'd withdraw my objection.) On the other extreme, note that when the code relies upon fewer assumptions, fewer changes are required to fixed the codebase when those assumptions change. If the original design is sufficiently clean and modular, there will be much less need for subsequent ad-hoc redesign. As a positive example, when someone in the UNIX world needs to deal with the Y2038 bug, they can hire a junior coder to edit one line in one header file, and then recompile all the binaries. No overpriced "Y2K" style consultants are necessary, because the code was engineered to be maintained in the first place. The problem can be "fixed" even by someone who is not a skilled programmer. That's precisely because someone who was a skilled programmer decided to make maintenance easier, even though it wouldn't be an issue for the next few decades. That's good design. That's what I'm talking about. The single biggest source of errors and unnecessary costs in software are those that come about as a result of viewing the mainenance role as a second fiddle, lesser skill. It isn't. I disagree. I think the single biggest source of errors and unnecessary costs are those that come about as a result of excessive code complexity, poorly architected code, and code that wasn't designed to modular and maintanable. For reasons of simple economics, a given maintenance role should not be filled by anyone significantly more (but never any less!) skilled than the job actually requires. Assigning to much or too little expertise is a waste of manpower or a waste of time, respectively. -- Ytrew	[reply]