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.