Thursday, 29 May 2014

Understanding Key Training Sessions

Rob sent me this a while ago, quite interesting to see that most of the trainings I was doing by myself were simples Steady Runs which I wasn’t really taking much out of it.


Long Runs
The long run is an important element of training but we often get obsessed with it, especially when training for a marathon. At first simply concentrate on increasing the time you spend on your feet rather than worrying about the pace or distance. The key is working at a conversational pace that is a perceived effort level of 6.5-7 out of 10 (65-70% of range of your Maximum Heart Rate - MHR). This may be a brisk walk, a run/walk or a run depending on your current fitness and level of experience. These runs improve your muscular endurance, running efficiency and your ability to burn fat as its primary fuel source.

Threshold Runs
Threshold sessions are one of your most valuable workouts but they do require some effort. They are run at level of ‘controlled discomfort’ that is a perceived effort level of 8-8.5 out of 10 (80-85% of MHR). At this level you are only capable of uttering 4 or 5 words to your training partners. You will find that these sessions require concentration, but they will greatly improve your speed endurance.

Kenyan Hills
Hill running of all types develops the strength in your leg muscles and tendons without putting them under the type of stress they are exposed to during faster running. Run up a 7-10% gradient for 30 seconds to two minutes at a solid steady pace. Turn immediately at the top and roll down the hill at a relaxed pace, then turn and repeat without any recovery. Keith Anderson discovered this type of hill session when he trained in Kenya with some top elite Kenyan athletes – so that’s whey we call them ‘Kenyan Hills’. They are one of the Kenyan’s main conditioning sessions. Like a Threshold run, during a Kenya Hill session you should be working at about 8–8.5 out of 10 and be able to utter about 4 or 5 words.

Fartlek
This is a Swedish term that literally means “speed play”. It involves a number of bursts of effort over a variety of distances with a variable recovery. Originally the length of effort was based on the terrain, for example, pushing harder every time you came to a climb, no matter how long it was. But you can adapt it for your needs. This is a great way of introducing some faster work into your training.

Interval Training
Interval training allows you to practice specific race pace speed and involves running timed efforts with a controlled timed recovery. The perceived effort level is 9–9.5 out of 10 (90-95% of MHR) and this is where you can only utter a couple of words at most.

Steady Runs
Steady running is carried out a perceived effort level of 7.5-8 out of 10 (75-80% MHR) and is running at a level of some discomfort. A lot of runners do most of their running at this level because they feel they are working but, in reality, it is not focused enough to be of real benefit and neither is it easy enough to be recovery. The result is no man’s land! We do however occasionally use this level of training when trying to develop your training towards Threshold effort or increase the general workload within the training plan.

Marathon Pace Practice
Understanding the pace you are able to run your marathon is very important. Pace judgment is crucial to running your best marathon. Marathon Pace Practice is about 7.8 out of 10 (78% of MHR) and allows your body and mind to get used to what will be required on the big day.

Warming Up
When you are going to do any faster running, such as Hills, Threshold Runs, Intervals or a race, it is important to warm up gradually. A 10-15 minute jog allows your muscles to gradually warm up and improve their range of movement. It also allows your cardiovascular system to prepare for the harder work to be carried out.

Cooling Down
A period of at least 10-15 minutes easy jogging and light stretching allows your body to adjust back to a steady state. Cooling down stops blood pooling in your legs and helps remove some of the waste products, such as lactic acid, from the muscle cells, which helps to avoid undue muscle soreness.

Recovery Run
Training for endurance requires your body to work hard but to see improvement, this has to be done without you getting ill or injured. You therefore need some recovery runs and these should be run at a very easy and relaxed effort. You should be breathing easily and be capable of holding a conversation throughout the run and your effort level should be at around 6-6.5 out of 10 (60–65% MHR) and your run should be no more than 45 minutes in duration. This allows your body to adapt to the training workload and therefore improve. It also helps with the removal of the waste products, which accumulate in your muscles after harder efforts.

Cross-Training
It is important that your training is balanced with some non-impact activities such as swimming, cycling, rowing, aerobics, etc, otherwise you are more likely to pick up an injury that will set back your training. But more experienced runners should also add cross training to their regime. Endurance running, especially the marathon, requires whole body-conditioning. To achieve this you should aim to work a variety of muscle groups and not just your legs. Remember that you are a runner and your cross-training should compliment your running and not be so intense that you are left too tired for your running sessions.

Rest
To help your body cope with the workload, rest is going to be as important a part of your training schedule as the running. Listen to your body and take heed of any warning signs. If you feel fatigued even before you’ve run a step, find yourself thinking up excuses not to run or start suffering a series of minor injuries, you probably need more time off. Taking enough rest allows physical and mental recovery and gives your body the time to adapt to your workload. Remember: on rest days, that is exactly what you should be doing!


source: www.fullpotential.co.uk / info@fullpotential.co.uk

Forget the carrots on a stick

Dan Pink: The puzzle of motivation

Monday, 26 May 2014

Climbing Holiday or Climbing Trip?

I tend to see some things in life in pure black and white. A climbing trip is one of them. I do not believe in climbing holiday. I go on holiday with my wife, I go on holiday to relax, chill out and appreciate the nothingness of live. Climbing is business. There is a goal, there is a purpose. You train for it. Day in, day out. You do not train for a holiday… You don’t go on holiday with any other goal but to chillax, eat, drink, party and sleep. You never (or almost never) come back frustrated from your holiday because you did not climb a specific long awaited goal, and as far as I can remember, unless you are travelling to some remote non-english speaking place that will require a lot of articulation to get even the minimal things done, you will never come back as wasted or cooked as I come back from a climbing mission. 

I don’t care what the dictionary say. Don’t give me this crap. No holiday blues compares to the sadness of sitting in a chair just a few hours after being on the top of an amazing alpine peak. Trust me on this one.

This is the 2nd year my plan to buy tickets ahead for a cheap attempt of the North Face of Tour Ronde has failed. Too much snow took us to Verdon Gorge in 2013 and again forced a last minute change of plans and instead of Chamonix or Courmayeur we head south for some multi-pitch sport climb in Finale Ligure, Italy. Although I was really keen for some alpine action it was a nice trip nonetheless. It almost felt like a holiday… good weather, easy days, birra moretti, calzones, good bed.. I was almost convinced. Except that I did not take any pictures. None… did not see a point… it was a failed mission, the plan C of the plan B… no. It can have lipstick but it is still a pig, right? Yeah.. It was not a holiday… I am frustrated :-)

One thing I can take from the trip is how it helped to measure my training. I can definitely feel my speed and fitness are improving although I still have a lot to work in terms of grades and more technical climbs. On Saturday we did L'Autunno dei Moicani (6a), 6 pitches, 150m and on Sunday we did I.N.P.S. (6b), 9 pitches, 200m. After 2 days of climb I was fairly fresh on the 3rd and could do all over again.

Random cimber high up on I.N.P.S., Valle Aquila, Finale Ligure

With me in the process of changing jobs, getting married and finishing my MSc it seems that this year follows my original prediction, a lot of training but not much real things getting done. My stag do in the Walker Spur doesn’t seem like is going to happen and unless I come out with something very ingenious, I am not sure I will even going to be able to do a real peak in the whole 2014. I guess considering how I abused my life and pocket last year, cannot really complain but still it feels a bit harsh.

Banana Altitude Test

Tuesday, 20 May 2014

'The Edge', 100 Years of Scottish Mountaineering (part 1 of 6)


How Technical Debt Threatens Your Brain Capital


This article was originally published in Scrum Alliance web site. Unfortunately in there the pictures and text formatting do not look as cool :-)

Technical debt succinctly and metaphorically sums up the obligation we incur when we cut corners during software development. Most articles focus on the direct association between "debt" and its financial implications; after all, money is the language the big fishes in the pond understand. If it doesn't threaten the pocket, it is not (yet) a source of concern.

I fully acknowledge that not all debt is bad, as  John Piekos  explains on his post, "there are often valid reasons for accumulating technical debt.  Perhaps the underlying architecture has some scalability constraints, but getting the product to market, in other words, harvesting “business value” ($, customers), is more important to the business.  The key is for the Product Owner and Team to explicitly know that this debt was incurred, and accept that you may have to pay in the future be willing to accept that obligation.”

As regards the “bad” debt, justifying its fix can be hard because it typically does not result in anything the customers or users will see. Such debt cannot be measure effectively therefore you can't really see the true effect of addressing it. The payment terms on this debt can be onerous though.  Usually the cost is time or productivity, sometimes both.  This article touches on another often forgotten point: how increasing in technical debt threats your business knowledge capital.

Some time ago, when trying to understand a piece of voodoo code (nobody knows what it does, how it does, or how it could even possibly working) I was amazed to hear my co-worker saying that "yeah, I know this is bad… John has a way of delivering stuff very quick, but he's not really good with OO”. My heart sank. Quick and dirty delivery is like sweeping trash under the mat. The guests always find the house clean but someday the owner figures out that something is not nice.. It SMELLS - Real cleaning has to take place but by then the dirty is plastered all over the floor and it will take twice as much to get the job done. That day at work my task was to try to break that cycle, through refactoring I would exorcise that evil dark code and bring enlightenment so that not only John could deliver quick, but anyone who happens to be in charge of working with that functionality. Take that Father Karras!

Code exorcism aims to bring enlightenment into the darkness of the legacy code

Technical Debt will slow you down and eventually stop you

Code is not bread baking. Good code takes time to prepare. Period. Having longer work hours won't add quality to the code. Adding more workers to the team won't build it quicker - quite the opposite actually. Code has to be concise, decoupled, scalable and easy to understand - you spend way more time reading code then writing code so it has to be easy to read and digest. Every time you leave "bad code" behind, with the promise of fixing and re-doing it in the future, you increase the debt. In the long run (specially in places where hundreds of developers commit every day) the impact of such debt is that features will take more and more time to be developed since coders will take more and more time to understand how to do it and to figure it out the possible effects that such changes will create way down the line.

One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. It's like a pick-a-stick game where a small change can cause the whole structure to collapse without you even being aware of it.

The snowball effect of accumulating debt

Developers fear changing the guts of the code - why bother to change a hairy huge enterprise size class if it’s working, right? The more you fear, the more you work around and through this cyclic process you increase your debt by adding layers on top of layers until you start asking yourself how such code could possibly even be working.


Avoiding debt increases the gap within the team

The Product Owner is part of the team. He’s got the mission of maximising the ROI by defining what the team will be delivering within the next Sprints. A healthy tension between the PO and the rest of the Scrum team is beneficial to generate the right amount of stress that drives the team forward in pushing to deliver more and better. It is like if the PO was the tough father pushing the kids to improve their grades, while the Scrum Master is the lovely mother who indeed want their kids to go better at school but also understands that they need some space to grow and mature and figure things out on their own so that they can improve not only in school but in life as a general.


By having a PO who constantly refuses to address technical debt issues you run the risk of having the development team mistrusting his decisions. It starts silently, with weird looks and faces when he/she leaves the room, to more behaviours like starting to question his understanding of the system, his prioritisation skills and even his appreciation of the dev team work since their needs are never taken into consideration.

This tension increases the natural gap that exists between someone who works close to the business and the ones who are in trench lines of development. The last thing you want is a sense of “us” versus “them” within your own team. When this happens a interesting and sad thing might also spring, developers will start inflating and hijacking stories so that they can inbuilt refactoring work alongside their tasks. Because they are done in the dark and not properly flagged, these refactors tend to lack enough discussion and formalisation and people within your team or on different teams working on the same product might start to feel left aside in terms of having the chance to suggest or discuss alternatives or other possible ways to go about certain architectural decisions and this only adds up to their stress levels.


Technical Debt is a morale killer

This is when things start to get interesting… 

morale
noun
    the confidence, enthusiasm, and discipline of a person or group at a particular time.

Keeping employee morale high is one of the best things you can do to instil loyalty and maintain a productive workplace. An artist satisfaction lies in being sure he performed according to his high standards. A musician would not be please by a poor performance, nor an artist with poor painting, so why would this be different for other kinds of creative workers such as developers? Would they be please by being “forced” to deliver poor quality code? Would you be happy feeling you are staling at your job?

Excellence is a matter of choice but at work, this choice is only real when you provide the right tools and environment for the ones who chose to excel. If the team spends most of your time firefighting they can’t learn. If you avoid dealing with your debt in a smart way you cannot avoid its growth or figure out cool ways to deal with it. 


I remember a First Aid course I’ve done a few years ago. The instructor asked me what would I do when arriving at an accident scene - there would be blood, people crying, screaming, people passed out, you get it. Who would you threat first? “The one who shouts louder I said.” He smiled. - “Wrong. You threat the ones that are not complaining. If they are crying they are alive. The ones who are not saying a word, these are probably the ones who are more seriously injured…”. The same applies to our work environment: you wake up everyday dreading your job, anticipating the headaches that are waiting for you the moment you arrive to your desk. The accumulating effects of this over weeks and months destroy the team’s spark and their willingness to change and complain about it. The moment they gave up moaning is the moment they've stop caring. Passion is lost. By this point it might be already to late to fix things.

Developers need to be praised. They need to feel that they are free and expected to excel in their roles, that they are adding value and making a difference. Developers are not code monkeys.


Fact - Technical Debt leaves you empty of good brains


Paul’s company sells furniture online. He’s got a real business to back it - big office with a few dozens employees, a large warehouse to keep all the goods and a small development team to take care of the website. He sees his business as “an online sale company” therefore the best he can do is invest in advertising to increase his presence on the web.

The dev team started by taking over an old website and building a nice interface on top of it but now it is getting harder and harder to add new functionalities or even change the code. They see the business as “a tech company who sells online”. The best Paul can do - on their opinion - is update the website so they can react quicker.

Paul’s main competitor recently started offering mobile phone access so that clients can easily shop. Paul’s team think they will need at least 3 months to reach this stage and they are getting behind… Does this sound familiar? In the new era of tech & web based companies, where clients come and go at light speed, and people like and dislike sites and technologies as quick, the only survivors are the ones who quickly innovate and adapt

To innovate you need good brains. You need great developers. These guys are not only motivated by a huge pile of cash. Good developers will make good money anywhere. Seriously. They are not attracted by money. This is implicit in being good on what you do, you are paid good. What they are looking for is nice atmosphere, good tools, good team, and great vibe. I have met developers who would code for food if they were offered the right challenge. 

If your company is famous for bad legacy code and lack of support to tackle it, you won't be able to keep the good guys. If you are not willing to improve your code up to modern standards you probably don’t even need these guys at all. Accept reality. Save company cash and get a few junior devs that will quit in a couple years but can get the job done one way or another. You do not need the best brains to do average work.

It takes months for a developer to get up to speed with the guts of your code, even more when it’s about bad and non-documented code. When someone leaves your team you are not only loosing an employee (to your competitors in most cases) but a whole lot of knowledge and information leaves your business with them. 

Demotivated people tend to react in unpredictable ways. They will speak badly about your business and its environment - in and outside the work place. They will quit without warning. People leaving affects team morale and even the way future potential employees see your business. Gossips about your work environment spreads quick around the dev community and once your business has established itself as a bad place to work it is very hard to get rid of this and attract bright minds.


Conclusion

I hope this might give you new insights and lateral ideas to stress higher up in the chain why it is important to have a reality check on how your business address or consciously prepare for acquiring new technical debt in the long road of the SDLC.

I believe the main point on addressing debt is not missing the chance of making good out of something bad. Yes, technical debt can be a pain but depending on how your company chooses to approach it can be a great opportunity to leverage the development team skills. Refactoring is a great opportunity to apply proper design concepts and bring less skilled developers up to speed with modern concepts and other best practices of software development.

Always keen to hear you thoughts complains or just stir the pot.

That’s all for now folks.


References