From the point of view of building a compiler this isn't exactly rocket-science, but just to recap on the fundamentals a Function is a named block of code which:

1. may be executed from some select area, maybe everywhere, in the rest of the code, and always returns control to the caller, possibly passing back a return value,
2. takes parameters, which may be positional or named, by value or reference, mandatory, optional or even of undetermined number
3. has its own scope and can declare local variables

Functions are the way (and for a long time were the only way) to manage complexity via Functional Decomposition (FD), the process by which blocks of code are split into functions in order to make the code easier to understand (and therefore easier to get working). FD aids comprehensibility by reducing duplication (i.e. removing clutter) and adding english language explanation in the function and parameter names. FD helps if, and only if, it is done well. Done badly it makes things worse.

Functions also introduce a concept which is so fundamental and mind-blowingly important to programming that it is all too easy to miss. Every function has a user and a provider: a separation of concerns which is the beginnings of Client-Server programming. User and provider need to communicate effectively since neither should know what is going on in the other's domain (i.e. for an effective separation and simplification of complexity the function writer should know nothing about how and where his function will be used and the function user should equally know nothing about how the function has been implemented). Programming languages give very little help in easing this communication. Documentation is the frequent resort of the inexperienced programmer but the best result comes from good FD (i.e. design) and the best possible choice in function and parameter names.

Steve Maguire in his book "Writing Solid Code" was the first person to take a close look at FD from the point of view of reducing bug-risk. I had been programming in C for 9 years when I came across this and I found it a real eye-opener. In particular until then the attitude of the function writer to the function user was one of "caveat emptor" (or "user-or"), even if the user and writer were one and the same person. Steve Maguire suggested that the writer should try to help the user not make mistakes when using his code by not writing functions which tripped the user up. Where Functions had divided the programming world with a big fence (frequently called the function library), this book tried to build a bridge and persuade the two groups of programmers to be nice to each other!

The section on Assertions is the only part of the book that I'm not sure I agree with, as my friend Sean once pointed out to me you shouldn't change the behaviour of a function between debug and release versions. I accept that, but the rest of the book is faultless and excellent.

Ask any group of programmers what language they program in and you'll get the expected answer (C, C++, C#, Java, etc). The truth is that we all program in english (or whatever our spoken language is). We punctuate in a computer language, but 90% of the information we gain when we read through a program comes to us in our native language. Although I shall come back to this later, I strongly believe that our native language skills are fundamentally important in the way we program, and that we need to think more about how we use our vocabulary and such things as prepositions, adjectives and so on. For now let me just say that trying to understand code when you have to refer to documentation every time you come across a function is like trying to read a book with a dictionary at your side - cumbersome and slow.

Functions are generally named according to "intent". One debugging technique I have found very useful is renaming functions from "intent" to names which reflect what the functions actually do, even if these names are somewhat long (e.g. rename "register_customer" to "register_customer_name_if_not_present_or_out_of_date"). The latter might seem cumbersome, but follow the trail of functions up and you may spot where user and writer have made different assumptions about what the function is doing. I wish we could also do this with parameter names but unfortunately there has been a decline in the provision of keyword, or named, parameters in programming languages (e.g. compare "register_customer(true,false)" with "register_customer(account_holder=true,overseas=false)", though I note that C# is thinking about bringing this back on a future release).

Before the days of OO all you could do by way of code design was FD plus gathering functions together into modules and libraries. This latter activity was "nice" but not really what design was all about - that was the FD. Now that we have, wisely, moved away from the design-up-front approaches of the past, FD has become even more important as an ongoing refactoring activity, as functions coalesce and explode in our drive to produce a solution which is rational and comprehensible.

Richard

The Principles of Software Engineering: start previous next

In Chinese philosophy, the concept of yin yang is used to describe how seemingly disjunct or opposing forces are interconnected and interdependent in the natural world, giving rise to each other in turn. (Wikipedia)

Yang (the more dynamic element) and Yin (the more meticulous) appear all over the place, including Computer Programming.

People, and hence programmers, tend to be more one or the other. I'm more Yang than Yin. Currently, with QuSheet, I'm going through a Yin phase, and I'm starting to chew the carpets, but since I'm on my own with this I have to concentrate on my Yin side and just get on with it.

In programming, Yang is the Creative phase: the time when you get your hands on that keyboard and start making things happen. It can be new functionality, but it can also be re-designs, refactorings and debugging. You kind of *buzz* when you do this sort of thing. Fly by the seat of your pants. Shoot from the hip. And other well-worn cliches.

On the other hand, Yin is the Tidying up phase: the time when you read through designs, if you're doing design-up-front stuff, or walk though code, or check through test scripts to make sure you are being thorough. It's when you pick up your note book with that list of all the things you need to sort out, which you've been putting off for a while, and start ticking them off.

The most important Yin activity, however, is providing Quality Assurance, rejecting all the code which is not clear or succinct, even if it "works".

To a Yang person, Yin removes the "bu" from Yang's buzz and leaves "zzzzzz". For a Yin person, Yang is just crazy hackery.

Yang and Yin is a little bit like the labels "doers" and "finishers"- but not quite. First of all, you need Yin and Yang all the way through a project. Secondly there is a suggestion that Yang does all the work and Yin tidies up, whereas it could be the Yin doing all the work and the Yang just producing disposable prototypes.

Both activities are necessary. In my experience Yang tends to precede Yin, which is why I've called it YangYin, as periods of creativity are followed by consolidation. Programming teams need a mixture.

The reason teams aren't properly balanced is generally down to the Development Manager or Team Leader that's in charge. These guys inevitably tend to favour either Yin or Yang programmers and if not careful will recruit invariably the one type. Since, in true Yin Yang style, the two programming forces are opposite it's very easy for the Yin (or Yang) Manager to think that the Yang (or Yin) programmers are useless and not want to touch them with a barge-pole.

Too much Yin means nothing gets done (short of a mountain of paperwork). Too much Yang means nothing ever works.

Richard

Twots use respect as a way of circumventing argument; i.e. "if you argue with me then you are disrespecting me". Generally it's not the Twot himself who demands respect as that is far too crass, it's the little group of hanger-on support Twots who do it on his behalf.

Part of this comes down to the sort of sychophantic behaviour typical of what we all know as "office politics". However, whether respect is being coerced by the Twot himself or by his support group, it is worth touching base on what Respect actually is (IMVHO, of course).

Respect is not universal - it relates to a particular area, discipline or activity. For example, I respect David Beckham's opinions about football, but I'm not the least bit interested in his opinions on anything else. Similarly I respect the financial opinions of a Chief Financial Officer of a company that has clearly being managed well financially. I don't respect his opinions on anything else either. Too many people, I'm afraid, seem to imagine that if they get to some elevated position because of "activity A", then they should be respected with regards to their opinions relating to "activity B". Celebrities do this in the public eye. Managers and executives of all kinds do this in firms and institutions.

Respect is never automatic. It doesn't come with age or position. It doesn't come with anything, actually, as it is also subjective. Respect is generally earned when someone does something which impresses you. An achievement of some sort, over and above what an average person might manage. Something that indicates exatraordinary ability or expertise.

Not respecting does not mean disrespecting. Neither respecting or disrespecting is the norm. 99.9% of people fall into that category for me, at least.

Respect produces guidelines, not requisites. I can still disagree with people I respect even on the subjects for which I respect them. I can disagree with them greatly even if I respect them greatly. This is neither arrogance nor disrespect. It is simply the right we all have to freedom of opinion.

If someone I respect ventures an opinion within the area that I respect them then I will, generally, give that opinion due consideration. That is all I am prepared to do, and even that is not guaranteed. If I choose to do so, it will be simply because I deemed it prudent and sensible at the time.

And that's it.

Most of the time I will consider an opinion entirely on its own merit rather than on the merit or otherwise of the person who says it. Respect wont come into it. Any non-Twot shouldn't be bothered by this.

Richard

TWOTS: start previous

I'm no economist but here's what I think:

First of all, there are two sorts of employment: fruitful and useless.

Either case is better than unemployment, since in both cases someone is getting paid for doing "something", and this is necessary for the distribution of wealth and to stop people either dying of starvation or burdening the wellfare state. Fruitful employment, however, produces something which is of use. Useless employment does nothing for society except the wealth distribution bit.

Fruitful enterprises employ people to produce those goods and services which other people want. Useless enterprises employ people to either waste time or to produce goods and services which nobody wants, needs or can afford.

The purpose of all those city-chaps shouting their heads off in the city is to move the wealth of the world away from useless enterprises towards fruitful ones. At least, that is their purpose as far as our society / world is concerned. It's what makes them fruitful and what persuades the rest of us not to choke on our cornflakes when we hear some broker calling himself a "wealth creator".

Of course, there is no over-all ruler-of-the-world employer instructing all those brokers to work towards this end. Instead, an act of faith takes place whereby we all believe (and hope) that if they are incentivised in the right way then this little neural network of greedy little robots will magically produce what we need. The only reason we believe this goes something like this: brokers wanting to make money for themselves will naturally back the enterprises which have the best chance of making money as well and these should be the fruitful ones since the useless ones ought to go bankrupt.

As an act of faith it is massive because it is so reductionist. There are probably a great many different outcomes for a broker-network to converge on, which we'll only discover when they happen. Right now we have a recession caused by one particular outcome: the emergence of a gamble which benefits the brokers without benefitting society.

Brokers know that when they succeed in making a gamble which wins, they gain, but if they lose, they lose their job. How much they gain depends on how much they win. On a loss, they lose their job, regardless of how big the loss is.

So it makes sense to arrange things so that the losses are rare even if that means they have to be huge. In fact, even if it means that the gambles are ultimately bad, as long as no one knows any better until it's too late. These gambles started with derivatives but have now become so complicated that it's very difficult to work out what the odds and gains are. All that any broker has to do is keep on winning and he will keep his job. Unfortunately his boss, or the person whose funds he's playing with, either lacks the expertise or doesn't care enough to ask how the actual odds weigh up.

Eventually, of course, the loss happens, funds disappear, the world goes pear-shaped, the economy re-establishes its win/loss balance, money moves about randomly as panic sets in, frequently over to useless enterprise or sitting in great big bank vaults doing nothing, and we get a recession.

The broker loses his job, of course, but by then he's rich.

All the best

Richard

Wouldn't it be nice if programming was like painting on a great big canvas.

Over here we'll stick Bacchus, just below him a little panther, up in the sky will be a ring of stars, and so on.

Some of the bits might be tricker than others but with a pencil sketch to figure out how much we have to paint and a little estimate for the hard bits, as long as we don't start changing our minds too much, we should have a pretty good idea of how long the painting will take.

Programming isn't like this. Unfortunately, it gives the appearance of being just like this, especially at the start of a project. It all looks so "doable" at first, then it all goes Horribly Wrong.

Why? Well, as soon as we start putting our metaphorical programming paint to canvas we start to affect areas that we haven't yet visited. It's as if, strangely enough, something about the way we've started to paint that panther has changed how we will later paint those stars. Even though we may be applying paint in the lower left hand corner only, the whole canvas starts to change!

And it changes in strange ways, not just by gaining background colour but by twisting and warping in multiple dimensions. If things get really bad, that little bit where you wanted to paint the stars disappears completely.

These problems are never foreseen. It all looks so simple when we start out.

What happens?

Programmers happen.

Programmers create their own nightmares.

Bad programmers create other programmer's nightmares.

Mediocre programmers do the same once the complexity of the code passes a certain theshold.

Good programmers know when they're getting into trouble and ask for help. The best programmers know how to avoid trouble. No programmer that I have ever met can guarantee to get you out of trouble once you're in it.

The biggest challenge faced by any programmer on any project is, therefore, himself. Staying out of trouble, and basically the secret to being a good programmer, comes down to two things:

1) Having the knowledge and experience to know what is good programming practice.
2) Having the wisdom and strength of conviction to employ it.

All the best

Richard