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

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

Programming made a major leap from the pocket-calculator style "data-in" into "a program" which produces "data-out" when computers became able to refer to themselves, so to speak, via the concept of "reference".

Initially conceived as having access to a memory address (and still the case in programming languages such as C/C++), this is now more commonly referred to as a handle, in the case of data, and as a collection of all sort of funny little things like delegates, method-pointers and so on in the case of code.

A data reference allows us to work with the address of data about which we either know nothing (weakly typed) or everything (strongly typed). The weaker the typing, the greater the flexibility and the bigger the risk of losing track of what we're doing (a polite description of a bug).

A code reference allows us to work with the address of some executable code about which we either know nothing (weakly typed) or everything (strongly typed). We can even jump into it and see what happens (see previous comment on flexibility).

Object Oriented Programming has allowed us to start thinking of both in terms of knowing certain, different, things about our reference targets at different times, according to our need. This is a tremendously powerful programming advance and so is, not surprisingly, one of the principles of software engineering all by itself (#5).

The basic principles, however, are still important.

Although template/class/code libraries have provided ready-made mechanisms for storing and sorting lists of data, there are times when building your own linked data structures results in clearer code. Genealogy provides a good example. Although you would want a master list of your population keyed by their name, say, you would want each person to directly link with their relatives rather than force you to keep looking up cousin "Jane" and her brother "Harold" and so on.

(Someone may argue against me with this, and unless performance is an issue (which it frequently is) there is an argument for not trying to maintain multiply linked lists (because it's an error-prone headache)).

Although high level programming constructs have largely removed the need for function pointers the "goto" syndrome persists in a way which makes me think it must be tied to an ancestral memory. C#, for example, wraps a function in a class in a weird "transparent" way and even C++ has pointers to class methods (an OO term). Then, of course, there are "exceptions", a goto by another name (IMVHO) with a transparent function pointer passed in by way of an exception handler.

Whether we like it or not function pointers seem to be here to stay in some guise or another so, again, it's a weapon worth keeping in a programmer's arsenal.

Richard

The Principles of Software Engineering: start previous next

Ok, you've finally managed to get rid of that Twot that's been wrecking your organisation (and, let's face it, they do - they don't just sit there doing nothing, they try very hard to show that they're not Twots by *doing* things (need I say more) ).

But you (a) want him to go quietly and (b) don't really want to advertise to the world that you've had a major league Twot in charge of some vital part of your organisation. So what do you do? You give him a nice reference!

And we can all guess what happens next.

And now you (another you) have recruited that Twot because, well, hand in hand with that nice reference he made all sorts of outrageous claims on his CV about how his previous organisation simply couldn't have managed without him, especially if it succeeded. Of course, it succeeded despite his efforts rather than because of them, or maybe it (or he) just got lucky (it's amazing how much luck plays a part in commercial success). If the organisation failed you can bet your bottom dollar that the Twot made a hasty exit before the blame could be placed on him. Either way you will struggle to find this out before you employ him.

So now you have got on your payroll an expensive Twot whose last employer is still celebrating having got rid of. If you agree that your people are your most valuable asset, try to stop this happening again by making sure your recruiting procedure is the most polished part of your organisation. For example:

1. Don't palm off recruitment to junior members of staff.
2. Look for ways of measuring ability in an objective manner.
3. Make sure your employees aren't rejecting recruits because the recruits are better at the job than they are.
4. Treat references with suspicion.

And if you are one of those unfortunate people who is about to recruit someone senior, and you have no one in your organisation who can tell you whether he knows what he's talking about or not, so that you are forced to rely entirely on his references and trust to luck (maybe if he associated himself with success last time, that success will magically transfer itself to your organisation this time), then I hope you receive some of that luck because you're going to need it. I dare say you will stick your Twot on a throne somewhere and give him lots of power and responsibility in the hope that by treating him like the hero you want he'll become the hero you need.

They very rarely do, but it's a nice fantasy - glug, glug, glug.

Richard

TWOTS: start previous next

The most basic principle is the one with which software engineering began, i.e. the idea that you can solve a particular problem by performing a sequence of steps. Computers owe their very existence to the fact that they can do this incredibly quickly.

Some programmers never really get beyond this. Others go so far beyond it that they need to be reminded (occasionally ) that the most elegant solution to a problem may well be a simple sequence of steps, declarative/functional programming notwithstanding.

Hot on the heels of the processing concept came the various flow of control programming directives (if-then-else, while-do, etc) including the infamous goto, which some programmers (me included) think is the worse thing in the world and others couldn't live without. Nothing very new has appeared since the introduction of exceptions, a concept still trying to find its feet between those who (like me) use them extremeley sparingly and others who think you should use them all the time (for the record, I use exceptions in abort situations and test-harnesses and rarely anywhere else).

Multi-tasking, which is where more than one process takes place in parallel (not necessarily on the same processor), has a strange relationship with software engineering. In many cases it isn't a software engineering issue at all, more a case of hardware configuration and software deployment. Multi-tasking becomes a software engineering issue when an engineer has to make the decisions on how to partition his software into asynchronous (i.e. independant) modules.

Although multi-tasking has been around for at least 25 years, it is relatively unexplored as an engineering technique. Separating functionality into asynchronous modules communicating to each other via pipes is easy enough, and occurs naturally at the boundaries between, say, an application and a print-spooler, or an application and an operating system (like Windows). Seaparating functionality at a fine grained level is also easy to do - i.e. everything talking to everything else in an asynchronous manner. It's not very efficient, though. The problem is finding the optimal middle ground between these two extremes, and this is totally dependent on what the program is actually doing. Where this partitioning happens, it tends to be done on the basis of module-cohesion - i.e. grouping together everything which is related in some fashion. Multi-tasking, however, is all about performance rather than elegance of design. Module-cohesion may not be a bad first attempt but something more intelligent is required here.

Well, single-task programming is hard enough without adding this particular complication - at least, for now.

It is also worth mentioning that multi-tasking makes a significant appearance in low level programming, where the behaviour of peripheral devices provides a natural multi-processing environmnent (and I include in this keyboards and mice). There is a little bit of technique here to do with polling-vs-interrupt, safe-areas, locks and semaphores which anyone involved in this type of work will have to be familiar with. Generally speaking the order of the day is to try to minimise any processing you do inside an interrupt (i.e. when you've stopped your main process in order to do something else). Failure to do this could land you getting into all sorts of horrible real-time bugs (been there, done that, have the scars to prove it ).

Richard

The Principles of Software Engineering: start next