Friday, 24 June 2011

Things to Know - Who owns the Technical Debt

A fresh release for us is due next week, have to say it has been put up with a serious effort of around 8 months with a lot of hard work and agility and comes with a lot of development contribution that is beyond coding and testing. Now that we are almost there, I have been reviewing the bugs created by our test team, ran an eye on the code to check through the code quality, ran on de-scoped features, made a list of items we could not do for several reasons. Going through this one thing kept on reminding a discussion Me and Savio had way back in 2007 when reviewing code for another product topic was "Technical Debt". For those of who are new to this term technical debt is the leftover or unfinished things in your development work [precisely a product/feature] that links to documentation, design implementations, re-factoring, coding. In other words if you choose to finish your product faster and in a messy way you leave a big technical debt behind. The day your development team starts saying that X things which probably is a small feature will take more time, snap out that you have some technical debt on you.

Technical debt is similar to financial debt, the only issue is it is not measurable in figures. You can find how much you owe to someone when it comes to money/interest, but with regards to a Technical debt its the price the entire Team pays by putting additional effort to do some basic things. Technical debt is caused by Deliberate Motives or Ignorance, though the quadrants may differ you can broadly say that technical debt cleaned earlier the better...

Typically deliberate technical debts are caused by

1. Lets do it now and we will see whats the impact later
2. We need to release this by X date
3. Put a todo list and we will revisit it later
4. Not now
5. Its too much work

Out of Ignorance causing technical debt can be serious..but usually you would see it happening due to skills and comes from freshers unless you don't have good technical resources. Many a times technical debt created out of ignorance comes due to the fact of ignorance in writing code, unawareness in knowing the best definitions of technology and language or available design patterns that can be applied. A lot of times ignorance is caused due to skill and understanding too.

Whatsoever said.. You can know your technical and the severity of it by :

1. Counting the number of bugs raised once the development build reaches the QA.
2. By the amount of effort your team spends on adding features to the developed items.

Eventually most in disciplined teams do not care about the technical debt, they live for today. Letting the code die a cancerous death tomorrow. This is another reason you would never find a owner for repaying the technical debt or someone who works on it in such teams. Of my discussions with Savio and have seen him work I have a few traits identified I think I must mention them here;

1. Everyone in your team owns the technical debt; everyone hence should share it and repay it whenever they can.
2. Code review ad-hoc times apart from the stipulated and process schedules.
3. Add TO-DO lists and log them into some place [Wiki / JIRA] so that they can be put in a roadmap sometime.
4. An Architect defines the technical roadmap to repay the technical debt.
5. Product Module owners have to visit and identify what needs to be done. The lazy bone's should be thrown out of the process.
6. Re-visit code based on the bugs raised to ensure priority is given to severity
7. Value the quality, talk about it to others and show them how to execute it
8. Every release should have at least 1 technology effort put up. This would be one way to encourage new joiners to contribute in quality efforts.
9. Project Management should be introduced to technical debt earlier in the project.
10. Introduce group code reviews and multi code reviews randomly to find and fix the needed.
11. Prioritise your debt; keep it listed and updated. Know it to fix it.

Certainly if you have more than 1 code owners in your team, who value the size, quality and robustness of your code base, day is not away when you will have a highly qualified code base that can do best to your team. Question to ask yourself:

1. Do you want to invest in creating these owners?
2. Do you believe that technical debt is killing your product?

Thursday, 23 June 2011

Development : What does Quality mean? - 2

Continuing our efforts on working and understanding quality let's now focus on the other side of quality for developers and development teams. What we should do before, after and during the development cycle's is the bright known side of the coin, but to be honest you may be well equipped to write the best products, but quality is not just ensured by writing very good code, planning better, reviewing.. there is another aspect of development that one should consider, specially for development teams. As a developer in my career I felt the need of some of these several aspects which were just not about programming but affected quality in several senses and ways...

Here are those other things that should be avoided / done to ensure development sticks and values quality..

Enjoy Coding, Love Programming,Live Development
It's not the same for those who think it is there are big differences. Coding is about putting syntax together to make something do what is needed. Programming is more complex, it is putting a design in place to get things work in the way they should be.. Development is about bringing a lot of pieces like coding, architecting, designing, programming, analysis, testing together. If you think just writing code is making you a quality developer, you are wrong. Get your gear up for the later..

Find your blockers first
Many of developers don't know what blocks them from doing quality work. Over years I have come across so many factor's that affected quality of developers work from silly to serious. Years ago I knew a developer who consistently wrote code which had several review comments, upon asking we realised that there was a clock placed right above his desk that would tick every second, give an alarming sound every 30 minutes, this would distract him so much that he started to put his focus on it.. funny? Meetings, Noise in the workspace, sitting arrangements, external sources like people walking in and out, people calling loud, ring tones etc make it difficult to concentrate.. obviously long term they start affecting what you do.

Find your Rhythm source
Some find music to bring them to rhythm others just a quite place. Each developer needs to find his own comfort space, and this comfort can yield focused effort, in turn support quality in work.
Stay Put
Focus is important. If you cannot stay put at your work place, you are more likely to be distracted by yourself than others. Obviously you are going to spend time doing things than finishing work that would result in slogging in the last minute to get things done. Obviously quality is the victim.

Garbage Collection is not just for Objects, for developers too
Many of you from technical world might know this term for those who don't.. it is a systematic recovery of stored resources used by your computer program that it no longer needs. Developers if understand that they put in a lot of thought in several things and they should have ways to recall some of that energy , thoughts spent in right time to un-exhaust them. This is just not about taking a break from your desk.

Google is not the only source
95% of times when asked to the interviewed candidate on what is the source of his/her information I got the same answer "Google". If I was a Googler I would be pleased. But as a Technology person no more. If a search engine is your source of information you are starting from step 1 and drilling down to where you want to go. In general terms Google is a right thing.. but is Google the only source?

I remember of StackOverflow, Experts-exchange been the general forums I referred to, Java ranch and Sun Java forums for Java, Quora for general startup things, Mashable / Techcrucnh for tech news etc..But are these not important sources? I have a list of 80 Delicious items that I know I visit every evening. depending on the last update index. You need to find the right sources and should turn to Google when you need it hard.

Make Forums your homepage
Forums... everyone wants to ask a question and get an answer.. but tell me, How many of you really give that answer? the quality of a developer improves with his contributions to the forums. Just reading and learning without contributing is shit. You may not be a good writer.. but if you share you learn, you evolve, you would unlearn and you would re-learn. Have forums your home page. See what industry or technology is facing as a challenge.

New Technology is a mirage
I have heard form many that knowing new Technology will boost there careers and help them write more performing, more scaling, more robust application. I am sure if you think that way you have not tried enough. Moving to a new technology is good. But the first attempt should be making the current one be good. Most guys who I found fascinated to change architectures with New Technology without sane answers are the same guys that would give excuse of technology limitations to do something.

Unlearn , Relearn always
Do you? If not start doing this.. A long ago I learn using java.util.Vectors was the best way to manage key/pair values. Unlearn things occasionally to re learn them in a better way. Now I know it is not. There are better options available and can be used effectively. This just doesn't apply to technology, just generalise this.

Yet again, I am sure there are many more things that will help you improve quality of the development process and what you develop. Point is.. The most important thing.. do you have a WILL to be a quality person, a quality developer, a quality craftsmen?

Wednesday, 22 June 2011

Development : What does Quality mean?

Let me begin by saying quality is over-rated and under utilized, under practised and over spoken. Most people do not understand the core meaning of quality.. for many quality means a bug free software, for others quality means anything working as expected.. it may be combinations of it, but been into Software business for more than 12 years I have understood that quality is a phenomenon that evolves and makes your life better. But anyways we are not talking about quality in general... let's begin talking with our focus on development first....

The prime element of a Software engineering team is the strength it posses within it's developer community. It means that these craftsmen who build the future of companies and the technology world are really really valuable resources. Now these craftsmen who build important innovations and structures are the one's who are most likely to define the quality of their art (Software they produce). Question is.... do they really understand what quality is? How to maintain it? Is better coding referenced as quality? What needs to be done to imbibe the valuable quality factor in the development?

I am sure there are lot more questions and dignified answers and clarifications to each of them with several more additional questions... When the development starts for a product, a project or a task there are a few things that your developer community needs to follow, understand.. if they don't your job will be to make them do...


1. Do understand the requirement
Superficial if talked about clarity of requirements??? It may not be well defined... yet it has to be understood and brainstormed... well you are right. You as a developer need to understand if you know what you are developing, for whom, when it needs to be done and why. The more clearer these answer's fall for the developer the better chances that the art will be fine...

2. Refuse
You need to refuse any demands of writing bad code.. I remember once asking a developer to produce code with some missing quality, in turn I got an answer "Do we need to build a baby with Polio?" You need to realise and make your team realise and hence refuse bad quality outcome's, un-realistic demands.

3. Define what?
It's important that you as a developer get an answer on what is the basic thing to be done, anything that is nice to have should be out. First get a primary list of what needs to be done. A feature list plays key role with importance and severity.. You can F**K the priority here.. I hate using that, because hardly few people realise priority is at the front end.

4. Can and Should
If you can doesn't mean you should. In the last few months I have realised that WE CAN is/was understood as WE SHOULD.

5. Pick what and when to do
Decide which features you would work on and when you will work on them. I know how much it sucks to work on a programming task when you have a severe headache... I remember Henrik (One of our UK Team members) saying... I am writing shit since my head is having a Diarrhea...

6. Choose your tools
Development IDE, Code repository, Integration tools.. All these help, review plug ins, code review tools etc.


1. Spend time sharpening your axe, not cutting the tree
Spend more and more time understanding the requirements, architecture, spend time in planning and designing than just taking up the task and coding. The more sharper your understanding the more faster you will write the code.

2. Test first, write next
First put your tests in place then write your actual code.

3. Do what is needed
I have seen many developers complicating the development process by throwing various discussions, scenarios, technologies and dependencies under hoods of unclear requirements, dependencies, technology limitations etc... do minimum of what is needed.

4. Keep it simple
Easy said than done. But try to write code that is understandable.

5. Document when you do it
Before you forget, write the code as you will die tomorrow and your son's bread and butter is going to be on the program you write.

I heard this very often. There is no first cut implementation of a feature... there is either a complete feature or a buggy feature. Write a code that completes the feature not just creates it...

Enjoy the work
If you are bored take a day off
If you love to work in a dark room, find one.
Set yourself into a real mode..

1. Review
Review your code, during the development, after you are done with it. Peer, colleagues, techies, experts.. just get anyone who can help review your code...

2. Re-factor
Re-factor when you feel it is necessary. Listen to the call of your developer inner soul. Re-factoring is like oxygen pill to the code, give it as much as you can.

3. Test Blind
Test like a end user. Don't wait for your testers or customers to find bugs for you. Reward yourself if you find a bug.

4. Re-visit
re-visit your code..whenever possible.

Well this is not it... as a development engineer the responsibility you hold is very critical and crucial... Quality has a broader meaning and as developers you can ease life of lot of others... in the end you are real Craftsmen not Robots producing some replica's

Monday, 20 June 2011

Things I learnt about Project Management

1. Managing one’s wants is the most powerful skill a person can learn
2. Projects success is dependant on executor's attitude's and not just effort
3. Budget should be the last thing to think of
4. Planning is over hyped, under utilized
5. The only time quality comes into action is when you are not reviewed
6. Manager's like engineers who fix things quickly.
7. Between the release date and code freeze lot of bugs are raised, requirements changed.
8. Requirements are changed like clothes (everyday), schedules like attitudes (never)
9. Lines of code fewer the better
10. Those who complain the most, accomplish the least
11. Features have incomplete requirements even after they are delivered
12. Agile becomes an excuse to not follow processes
13. Code review should be scheduled like checking emails are
14. The guy who writes the worst piece of code, is the guy who is more concerned about quality
15. Scope, quality, time and budget never meet at one point.

Many Many more, coming into phases.. What's your learning's though?

Friday, 17 June 2011

How to find an angry employee

Do you have an angry employee at work? Do you know how to figure out one? Well here are the quickies to start with and with your help we can build a good list here, of course we can then use the list to figure out the reasons and also find answers and solutions to them but let's say that these symptoms don't need to be merely due to conflicts they can also be due to pure unhappiness, unwillingness to co-operate etc, but it's a good start to build one...

usually these symptoms range as :

1.Not completing work on-time
2. Gossiping about work, company, office, Boss, colleagues
3. Not responding to phone / emails / aggressive in language and tone if replied
4. Avoiding the morning wishes and day end see off to colleagues, team members, Bosses
5. Trying to find excuses on behavioral changes
6. Hoarding information that should be shared
7. Complaining , whining
8. Blaming others for their acts, sometimes openly, sometimes in groups
9. Verbal abuse
10. Not attending required meetings, popping up late
11. Uncalled expressions
12. Absenteeism
13. Physical violence

There can be many more small things but they fit into one or the other of them. The type of behaviour an angry employee pick also signifies the mode and nature of conflict/issues. So do you see any angry colleagues? How can it be reasoned out? How can it be solved? How do you turn your angry mates love you? Well a part of the series that I started at How to get loved by your Team can be used in building this solution... So what more do you see?

Working with Talents

I recently asked our leads a question "Who are your Star team members and who are your mediocre performers?" the objective of this question was to put a clear vision on how to map the average performers to be the star team members. I am very sure with your teams you may be facing the same issue, a whole bunch of average performers and a small lot of star performers. Swami called this term "A Pyramid" the top performers are like the tip. Although I have to say that marking talent into various cadres is really pitiful, but you are left with no choice when you calculate the value these talents bring to your organizations. Let's take an example of an engineer working for your team, To ensure that he does what you want him to do you set his KPI (Key Performance Indicators) or Key Result Areas, you define his role and responsibilities, the expectation from him. When you review his/her performance you would realise that someone who is just able to achieve his/her KPI's is termed to be doing average/good, someone who is doing it exactly how you would have expected and maybe bit more is considered to be the Star performer in the big groups/organizations. In this regards most times organizations/managers want people who can just do what is asked with some support/supervision/help. They all form a group called C level talents.

Accessing talents across you would realise that most talents that stroll around project teams in bigger or smaller companies (Not talking about startups) are the C level talents. Most of the C level talents struggle to fulfill their roles and need supervision and help in the fulfillment of their jobs. To be honest most of the C level talents do not know how to do their job well. While excuses of no clear specification, other factors, motivation, growth, capability and skills drive them to be C level talents, they can be worked upon and mentored to be B level in a long run. Most of the organizations that do recruitment through job portals, consultants and web portals really hunt for the C level talent.

B level talents are hard to find.. I have to say they are hard to find in big or small companies (Again leaving startups out) specially because apart from doing what they are expected to do they take an extra mile in achieving more. B level talents drive your teams to do more. These talents play crucial role in evolving processes, outcome's, results and are committed to the future of the organization and growth of the team in all possible ways. B level talents are the initiators to improvise things, they are participative, vocal, hard working and ensure that they contribute in many ways. B level talents have hunger to succeed and want to make a difference in shorter span of time, another reason why you would find a lot of B level talent in startups and Innovative companies.

Now with the above 2 explanations you may have learnt that the real stars are A level talents. They could be the Ninja or rockstar engineers of your team. They ensure challenges are handled, things are done without been asked for, improvisation is inbuilt. They are the real go getter's and are drivers in educating, implementing and executing success for the organizations. They define direction for the teams and organization, products and vision of the organization. However A level talents don't come through job boards they have to be found through their proven skills and by references.

In plain words.. Anything below the C level talent should be made hard to find ;) and startups should focus on making C and B level talents innovate, learn , make mistakes and evolve.

Thursday, 16 June 2011

Happiness quotient, you and work

I had a classic debate a day ago with one of the colleagues talking about Happiness at work. He mentioned that the happiness drivers for him or anyone are good work, good company, good money. When I asked what is replaceable, he said as often 1 of them has to be compromised... Misery eh? So being into a renowned company, earning great money bring smiles to your professional face? I am not sure.. the matrix's of these 3 can be different and have different meaning to different people.. What if you are working for Facebook or Google and doing a shitty job? What if you are working for a very small company, doing great work and earning peanuts? What if vice versa?

Well you cant link your happiness quotient to good Company or money, they are external factors really, they change. I remember when I started my career my happiness quotient always started and ended at "learning's", as long as I was learning I was happy. Things evolved and they tuned to improvise and factors affecting happiness increased..Now 3 things that drive my happiness quotient at work remain to be constant:

1. Am I working with great people
2. Am I working on challenging assignments
3. Am I contributing to the ones who are working with me.

Either of them fails, it hits this quotient,drills distorted view in my routines, creates pragmatic effect on work and professional life. My understanding with the drivers of happiness quotient is fair and simple..

1. If you are working with great people you will learn, evolve, achieve expertise.1 important thing that I have learnt working with great people is that they empower you to do critical tasks, jobs , things that you are told and not told.In other words you can grow leaps and bounds with them. Great people throw challenges at you, make you work effectively and also ensure that you are guided appropriately. Eventually it is great people that make companies good and good companies guided by great people ensure good people get paid well and are happy.

2. If you are working on challenging assignments it means that you are skilled and challenging work enhances your skills. If you are highly skilled you tend to achieve growth as it is an inherent part. Not to question challenging work will show where you stand every time you do it, as if it is a kind of reviewing your skills and potential.

3. If you are contributing to others one way or other, technically or non technically you are improvising your skills and making yourself great within(Teaching is learning again). Everyone likes to be (called) great, contribution to co-workers, mentoring and coaching demonstrates your potential leadership skills in turn exposes your greatness.

Considering these factors.. I happen to believe that extrinsic factors cannot define one's happiness at work.. it is the intrinsic element that drives your happiness. If you really want to be happy at work you need to first figure out what is it that drives your happiness? what defines your happiness quotient at work? Think over.. come back.. let us all know...