Hazards of sitting

Having been reading monthly occupational safety reports at work has increased my consciousness on safety related to work in general (very good for preventing some stupid home injuries) and electricity related risks (also very good thing to know if you are the kind of guy who doesn't fear to make some minor changes to home electricity, like installing a ceiling lamp that doesn't have the fancy and safe kind of a plug for connecting it). Other than that, I guess, for a guy who sits at the desk all day long the most likely accident at work is slipping on the office floor. And oh yes, I have once dropped a thick folder full of papers on my big toe, which resulted in a small bruise. Probably not reason enough to request for safety shoes with anti-slip soles and toe protection, though.

Those reports and subjective experience has also increased consciousness on the fact that long term sitting in front of a computer is a hazard to one's health. Not an acute one, though, and perhaps it is not that high profile on corporate health and safety agenda - except (hopefully) in software houses. Generally computer work is taken as such that it can be done in a condition where manual labour is not anymore possible (the most important muscle in a specialist is the brain, anyway). However, there is potential for many kinds of pain which might even be debilitating and thus affect productivity, so to me it looks a very real threat for working health.

I remember times when stiffness and tension caused by crouching over the keyboard was easily taken care of by some physical workout, stretching and a walk outdoors. By that time I didn't do yoga asanas, but I'm sure those would have worked, too.

I miss those times. Nowadays I'm happy if there is no notable tension and the stiffness is not painful. I've increased my awareness on the condition of my body as well as my posture, and I try to have short breaks during the day for doing some exercise and stretching at my desk. I do asana practice at least a couple of times a week, and have tried several kinds of treatments and therapies (different kinds of massage, acupuncture, reflexology...) and go to work by bike or foot. I ran into a good article on the subject and the theory given there on the reasons for the continued stiffness and discomfort seem very logical to me: the stiffness kind of works its way into the different tissues and thus in the end it's not just the muscles that behave badly.

So far I haven't used any occupational health care services since the situation is not outright bad, but I'm concerned of the directions of things for the sake of myself. I'm also pretty confident that the condition is indeed profession related (type of profession and condition do match).

The thing I'm happy about is that there is one common computer job related injury that I've managed to prevent so far - the carpal tunnel syndrome. I've been paying a lot of attention to hand ergonomy since pretty young which must have helped a lot. Maybe if I had been just as aware of the possible results of bad posture, too, things might be now different...

The reason I'm writing this is that during all these years I haven't met too many colleagues who would have indicated that they are really aware of these things. It's pretty common for office workers to go a gym regularly, and that is most likely a very good thing to do. Many might also have other hobbies that are good for the upper back area (I've heard that for example golf is great physical exercise in this sense). However, I fear that I'm not at all alone with this issue and it's worth the effort to bring up the subject.

Thanks for reading and now go do some stretching and make your body happy!

Of house and systems building

It happened that one evening I was watching the episode of British TV series Grand Designs which was portraying a usually overly-optimistic and imaginative house building project in Exeter (you may be able to view the episode via youtube). The gotcha of the series is that all the projects are focused on truly grand designs, leading almost always to a doubled budget and severely stretched schedule. Now, if that doesn't sound enough like an average system development project, let me add that quite many of the building projects also have legacy components (all kinds of conversion and extension projects) and the plans are modified along the road to accommodate to the failing budget and/or schedule - or the changing vision of the project owner(s), and the project is not necessarily led by an professional of building industry or architecture.

This specific episode was somehow unique in the sense that this time the plans really were changed remarkably in key points multiple times as the project went on, and the host of the show looked really doubtful of the chances of the owners ever getting a decent house. As usual in the series, the end result indeed was a decent house, unique for sure but not in a weird way, and definitely not ugly to look at (I wonder if they just leave out all the miserable failures or if the house builders just are so darn lucky).

Software or system development projects have been compared to all kinds of more traditional projects in the history, and software industry also has tried to take influence from other industries (like lean that originates in car industry). The inherent differences between software and its comparison points that might make the metaphor lame are debatable, as cars and houses (and maybe even more so the huge projects like bridges, dams etc, not to mention nuclear power plants) really are quite complex and technical these days.

The text book recipe for success is to have a rigorous working process that is not abandoned when difficulties arise, to avoid touching legacy parts when possible and to have professionals that are knowledgeable on the task they've taken on all levels of the project organisation. Many times it just doesn't go like that, I think. Many times there will be a sort of a cowboy mentality, "agile" or perhaps better called anti-agile (as it does not have much anything to do with the definition the signees of Agile Manifest had in mind) way of working. Many times it is indeed the legacy parts that need to be touched, which is harder, more expensive and more error-prone. Many times the key persons might be professionals of some other trades than software (no-one really expects non-coders to code, but surely any person with a technical mindset can be an architect, and financial skills are enough to lead the project because then the project surely will be on budget, right?)

The success rate of software projects is not very flattering. I've not got any recent figures at hand, but Robert Kraut and Lynn Streeter referred in 1995 in their work "Coordination in Software Development" to Robert Blazer's statement dating as far back as 1975 (!) and said that software still is unreliable, delivered late, does not respond to changes, doesn't hit the performance target and is expensive. Well, has that changed since then? I cited that paper in my MSc thesis in 2007 and my conclusion is still the same: that does still happen in large numbers.

Looking at the news here, I'd say that the success rate for building projects is not very good, either, especially the ones that are not large and demanding enough to clearly require the best practices and the best people. Just like the resulting software is likely to have security issues, the resulting buildings (at least in this country) are likely to have issues with moisture and/or unhealthy athmosphere inside the building. Neither of those would be hard to avoid, though, either by thinking security already in the design phase (for software) or applying basic building physics in the design phase and carefully sticking to the plan through the building phase (in construction work). But like in the TV series, when asked about the expected end time, it can be found out that there is no detailed schedule, and the project owners have the habit of changing the design as they go along (each change perhaps leading to other changes), and the project lead might be technical, but not exactly from the right branch of science...

As for the couple that featured in the TV show, I have absolutely nothing to say to how they dealt with the house they were building for themselves - it is solely in each one's own decision and risk. After all, they were amateurs when they started the project (as much as I am what comes to building a complete house), and should thus be allowed to learn as they go. However, the same mentality and way of working would be very strongly objectible if it occurs in the context of professional work.

So, what all this babble boils down to, I assume, is that some software projects are either led or completely run by a bunch of amateurs, or a bunch of people acting like amateurs, which is sad and unfortunate (both for the industry itself and the users of the software). I'm not into poking fingers at people, and I must confess that I've done plenty of amateurish mistakes so far and likely will discover new amateurishness in my actions in the future. Live and learn, or should I say fail and learn...

Since my sources are a bit dated already, I did some quick googling on the current situation:
Why Projects Fail - Facts and Figures
The Failed Record of the Software Industry

2010 IT Project Success Rates

It would seem that there, indeed, has been some improvement, and the agile movement really seems to be able to deliver what they've promised. However, the papers referred in the above sources still contain the same complaint and worry: that it is the people who make the projects fail. People, who do not act in a professional way.

From a certain angle computers creating their own software sounds like a good idea, even if it is quite sci-fi sort of an idea...


Post addendum

Some more survey results:
http://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail/
http://www.galorath.com/wp/software-project-failure-costs-billions-better-estimation-planning-can-help.php


And then yet later on (13th Nov 2013):
A good example of a gigantic failure in a gigantic project is the US healthcare.gov project that has been under scrutiny lately.

All work makes Jack a dull boy?

Sometimes I've been pretty frustrated over the fact that I need to worry about my employer's business also outside the office hours. That's an unavoidable side-effect of administering a production system, I guess, and it does not diminish at all by lack of quality within the administered system. I mean, I do like my job, but I also do like the rest of the stuff I like to do when I'm off-duty, and most of all I do like to sleep at nights. Unfortunately the system has its best time window for service from 10 pm to 4 am, which completely overlaps my best time window for sleeping. And I do have trouble getting sleep after late night work.

Whining aside - since that is the point in this post, at least so far - I ended up seeing a documentary about the poor people of India called Nero's Guests (this was actually already last summer, but never mind, and I think everyone should educate themselves with that kind of documentaries but that, too, is not the point here). One of the people portrayed there was a single mom of I think 3 young kids who worked a long way from home. She woke up around 4 am, washed up, cooked breakfast for the family and went to the train station at 6 am. After the day of low-paying hard work she returned home on the train after sunset around 23 pm (her kids obviously had had to take care of their own dinner since they were already asleep by the time their mom got home) and went to bed. I don't remember the details anymore, but I'd guess that went on seven days a week (or maybe she was lucky and was able to have one day off from work per week). Compared to that, the discomfort of having to work 37.5 hours a week with occasional hours hitting outside of the oh-so-convenient 9 am to 5 pm window is minuscule.

That is not by far the only example. Like the farmers of yesterday, the poor of the world today do not have a separation of work time and free time. And I think farmers still have the same schedule that nature dictates (work when needed, rest when you can). Not exactly the most prominent role models of today, but what is it that they seem to actually cope better with their circumstances than me with my own?

Actually the habit of having to be at the office from 9 am to 5 pm was inherited from the days of industrialisation in the 19th century, and has not much to do with the current ICT work that is not tied to place or time. In a factory it was - and to some extent still - is crucial to have the people at the conveyor belt (or the monitoring console in a more modern factory) all the time, otherwise the production will likely suffer. Since that is not the case with modern information work, we have things like flextime (ok, that's rather old thing already), remote work and flex work. Basically the information workers of now can put in their effort at the time they feel most comfortable and sometimes even in the amount they feel comfortable with at that particular time. Working in cafés, park benches, sofas etc is kind of trendy these days, and even the less-trendy companies start allowing that kind of work.

I've been doing flexitime all my career, and I appreciate the freedom it offers. I also appreciate that my current employer does allow occasional remote work days when I need it (although I do have better ergonomy at the office, so working a full day at home is rather heavy physically). This clearly shows that I have absolutely nothing to whine about in my working circumstances - so far I even got the luxury of a private room at the office (remains to be seen how long) - something not so trendy but yet so beneficial for concentration.

I've been working with my mindset some time now to mend this mental issue of mine. As I'm interested in yoga I like to view it also from the karma yoga angle - some things just need to be done due to that being my duty (applies also to the multitude of things not so pleasant yet mandatory in life in general). If I was as enthusiastic about my work as some are, things would be easier. I wonder whether it is about having a "perfect" job for oneself or whether it is about the mindset, or both. Nevertheless, not all can have a "perfect" job. In fact, "perfect" is something that likely does not belong to the domain of material life, so it must be about the mindset. It is rather ironic that if one sees things in a positive way, everything is so much easier.

After all, I'm being pretty darn lucky.

The yoga of software engineering

Time to finalise this post, it has been brewing there already for some time now...

The following is an attempt to map raja / ashtanga yoga to software engineering. The connection between the two might seem a bit vague at first, but let's see if we can find something in there...

Ashtanga yoga, also know as raja yoga or classic yoga, contains eight limbs or pillars or steps or whatever you want to call them. They prescribe the students how to progress on the path to the ultimate goal, which in case of yoga is either union with the God or realisation of the God-like part in themselves. With relation to SWE the goal might be to build a piece of software that has maximum compliance with the requirements, performs cleanly and swiftly, has good user experience and is secure. So the yoga of software engineering is about developing oneself in the profession so that one is, some day, honored among both co-workers and customers for being an efficient worker producing quality code and known for not straying from the golden path of best practices.

The first two pillars are yama and niyama, yama meaning self-restraints (what one should not do) and niyama requirements or obligations (what one should do). They help building the ethical platform without which the rest of the path will most likely fail to lead to the desired result.

The five yamas are ahimsa (non-violence), satya (thruthfulness), asteya (non-stealing), brahmacharya (sexual abstinence) and aparigraha (non-covetousness).

1. Non-violence would mean (in addition to not abusing anything or anyone physically) in the context of SWE to not violating any interfaces or specifications etc. 
2. Thruthfulness is easy to see in the context of pretty much every aspect of working life, with SWE that would mean being truthful to both the team and the customer, not hiding bad code or compromised design decisions but confronting and solving them before they give rise to more serious issues, and telling the customer the real status of the project and not trying to cover things up. 
3. Non-stealing means one should not literally steal code (unless licensing permits such code-reuse) as well as not violate any licenses but perhaps also not stealing the time of ones co-workers. 
4. Abstinence from sex... well, that might not be required in SWE (even though a stereotypical coder might get intimate as rarely as a monk), but abstinence from activities that drain time and energy from the yoga of SWE might be a fitting interpretation. That could mean abstinence from fulfilling ones lusts, which might include things like hanging out in social media or gaming sites during working time, or even cheating on ones employer by doing some work for other parties (i.e. professional adultery, unless permitted by the employer). 
5. Non-covetousness (or non-greediness) can be seen to mean both not trying to gain personal glory and/or benefit and also referring to holding unto the KISS and YAGNI design principles. Also trying to include too many things/functions within a module/class should be avoided.

The five niyamas are shacha (purity both inside and outside), santosha (contentment), tapas (austerity), svadhyava (study of religious books and repetitions of mantras) and ishvarapranidhana (surrendering to God).

1. Purity is needed both in design, code and personal hygiene, so keep both your design and code neat and clean, keep your head clean so you can think straight and get a shower more than once a week.
2. Contentment is required to be able to adjust to the limitations so that no precious energy and time is used on fighting wind mills.
3. Now there is a sanskrit word with rather varying meanings, but it might be seen here as having to take certain amount of discomfort along the way of meeting the goal. If we're gonna advance, it will take practice over an over again. Some of the connotations of the word also can be interpreted as holding KISS and YAGNI dear.
4. Study of SWE books is, of course, necessary to improve one's professional skills on SWE, and it might even be helpful to pick up some good quotes (guidelines, one-liners etc) and remind oneself of those things repeatedly, thinking about what they really mean.
5. Total surrender to anyone might not be the best thing for a SW engineer to do as individual thinking and challenging the current design is a good way to improve the design and thus the resulting piece of software. But curiously enough, many experts of their trade are highly dedicated to the thing they are doing, and certainly that does also apply to SWE.

The third pillar is asana, which in yoga tradition means postures (which is the only part most  people ever know of yoga). Asana practice is meant to develop one's tool (the body) so that it is fit and properly diciplined for the challenges that follow. In SWE one needs also proper practice (just read Practicing Programming by Stevey Yegge if you feel like disagreeing). Coding itself is not enough to develop oneself, since there are always external constraints that dictate things like how much time there is for a given task - which prevents adopting new methods or tools that would need time to be learned. If there is always a hurry to get an adequate solution, when will one have time to implement good (or even excellent) solutions? From my experince I'd dare to answer "hardly ever".

The fourth pillar would be pranayama, which in yoga tradition means controlling the life force, but like this part is done in the yoga tradition, I'll leave that and the rest of the story for the private teachings passed from the SWE master to his or her disciples. Besides, I wouldn't even be competent to give any deep teachings - being in dire need for such myself, too.

How quality degrades

I by no means assume the following does not fall into some sort of logical pit along the way, but I hope my idea will be conveyed anyway.

On a layered architecture each level has its individual degree of quality, but the total quality is not a sum over the parts but more like a multiplication over them, meaning that adding a top quality layer does not improve the whole (if not makes it any worse, either) and adding a less-than-perfect one will drag the total quality down somewhat. Adding quality would actually mean fixing a bug in another layer, which is not a good idea to do anyway. The whole can be as bad as the worst part within it.

What does that mean, then?

This week I took my first run on a web-based service for creating, editing and publishing video content. All the pain of being able to produce a nice enough, coherent and clearly voiced material aside, I also ran into some problems with the tool itself. I do not know if the service itself had occasionally some trouble handling all the traffic, or was my network connection bad somehow (the office WAN connection is known to have latency issues), or was it the fault of the browser (tried both IE and Firefox, though). Nevertheless I ended up logging in and out and restarting the browser and lost two good audio takes due to all that, which is not adding any glory for the service or its provider.

How are regular users seeing that kind of things?  They point at the service provider and say "your service is not good" as they do not see the different pieces in the whole. Is the service provider at fault? Many times that might not be the case. Does the reputation of the service provider take hit? Yes. Does it take the user support person a great amount of patience to get through the idea that the service provider does not (and can not) be responsible in any way of what there is between the user and their network? Most likely yes.



Thus, it is really important to ensure top quality all over the stack, and also beware of the pitfalls of having your product being stacked with layers you have no control over, since it may affect your brand. There are of course ways to protect against things like network twitches etc by properly handling all error conditions and taking care of handling communication time-outs gracefully - all signs of good quality software!

On (mis)communication

Reading a district manager's blog post on (mis)communication on our intranet made me think. His point was that although everyone is complaining on being assaulted by too much information, there is not enough communication - or more precisely it does not reach the audience.

Today I have communicated by unstructured means (email, instant messaging, phone) and (semi)structured means (ticketing system, supplier wiki) and I must say that I love the structured way for just that, structure. There is too much unstructured information flying around. Even though IM and email are fine for short term use, IM discussions are just a mess from archival point of view and email... well... there's simply too much of it. From a well structured wiki or a ticketing system you can find the information easily and stay updated on the state of affairs, and they are maybe even easier for the author (no need to think of who should receive the message or to keep references to things said and done earlier).

But blogging, yes, I was going to say something about it... What I find a huge problem at work is to reach the users when I have some instructions or tips to share. The usual way would be to send email to a mailing list, but the same applies to those emails as what is the district manager's grief - the message does not reach the receivee (or at least it does not get fully through). If there is more than one sentence some people stop reading, and if the subject does not immediately feel important to them at that time, they ignore the message (and thus I need to repeat the same things over and over). Besides, passing instructions by email is bad just for the reasons email in general is bad (hard to find anything after some time has passed). Thus, having a blog on the intranet struck me as actually a good media to both share some simple tips and also to notify people on new instructions that might be stored somewhere else. If the blog gained followers, it might even work as a feedback channel for development of new features (or gathering knowledge on what the user base really would like to change). A colleague of mine actually has started a blog of his own on just the same purpose, spreading out the word on current issues and hot user tips.

The downside of adding a blog to the array of the existing communication channels is obvious - one more thing to update (and for the audience one more to follow). And it is a big if whether enough users really bother tinkering with the intranet to actually start following a blog. Then again I think the potential is great enough to take the chance and try it.

Skill set - breadth vs. depth

I came to ponder upon the value of ones skill set in relation to its breadth and depth, and due to the inherent nature of human being also ended up comparing the options.
In my experience, what is most commonly sought after in job openings seems to be the type with deep knowledge on some limited domain. Only very rarely somebody seems to be clearly seeking a "ICT handyman". On the other hand it also seems that sometimes they are seeking for the ultimate expert with deep skills in dozen domains. Anyway, being more like a guy with broad skills it is a bit discouraging to find so few job postings with a spot-on requirements. Not that it would be crucial at this moment as the current position feels both suitable valued but you know, better safe than sorry and thus its good to have at least a vision of a exit plan.

Whether it is about diverse interests or just my "professional karma" that I seem to end up doing all sorts of things and thus getting a rather broad experience. Havnig done coding in dozen languages on at least three OS families, user support, reporting, system administration, DB design, network related tasks, all sorts of data extraction and analysis and getting familiar with various OSs and user interfaces it is clear that most of that might not be so ashtonishingly deep knowledge that would require anyone to drop one's jaw - but rest assured, it will get the job done. It also guarantees that I can throw myself into such obscure things as printer operation on MVS or rescuing a crashed PBX info system on a Digital Unix box. Challenges that nobody expects to have (both the platforms in these examples are long obsolete) but still somebody has to deal with them when the need arises.

This is not to in any way say that somebody with deeps skills in something would be somehow worse - in contrary I admire people how really know their stuff inside out and from top to bottom. We also need those guys, as without people like that nothing really fancy technical stuff would not be here since all that requires tackling such obscure issues that no lay man can even imagine. I also need those guys since if they were not there I would have no source of help after running into a wall in attempts to solve some hard issue.

Basically this seems to boil down a all embracing notion that both types are needed to form a good ICT team: those that have tackled the task already earlier and are willing to do so again, and those who have not done that but are definately willing to do it nevertheless. The former onces are more productive in the specific thing but the latter should be just as good for a broader spectrum of things.

Of course, this is just my personal opinion and as subjective as it gets, opposing views are more than welcome!