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?

Read More

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?

Read More

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...

Before

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.

During

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.

6. There is no FIRST CUT IMPLEMENTATION

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..

After

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

Read More

Say NO TO AGILE

I had a 15 minute debate today with a very good friend. While I started this blog, I had just finished the conversation and while I finish this blog I have decided to give him a call and tell him DONT THINK OF AGILE..To give a bit of a background to this... I received this call just 30 minutes ago where a friend banged greetings and then asked "Is this Agile any good?".. A few questions and I was sure that Agile is not working for him... Going over those thoughts and discussions I really feel pity when people without understanding the need, necessity and requirement of Agility rule out the benefits, perks and values of Agility. I have no hesitation in saying that Agile is not just about a process... I think Agile is more than a attitude... And if you want to find and enjoy benefits of Agile.. you need to be prepared to learn, invest and work on Agile Teams.

So what are those things that should act as a hint to you.. so you can make this decision to say NO TO AGILE? As a manager, lead, stakeholder, product Boss or CEO.. you definitely need to understand when and where you SHOULD NOT do Agile...

1. When your Sr. Management thinks every feature has a fixed number of developer days.

2. When your Organization thinks that a product is just fully ready as a requirement document or mockup is

3. When any of the following do not understand what Agile is CEO, CTO, Product Manager, Development Lead

4. When any one in your team thinks Agile is ONLY for co-located teams

5. When anyone in your team thinks Agile means no due date

6. When anyone in your team thinks Agile is a PROCESS and it should be strictly followed

7. When anyone in your team thinks PROCESSES and reports make products and Agile is just another one

8. When your Product owner does not know how to progress with the product

9. When your product team thinks that the feature can evolve as the development proceeds

10. When your product team does not document clearly on what they need from development

11. When your development think that Agile is for extended development time

12. When your developers value completion of feature more than quality of the product

13. When your development is only about coding once and re-visiting back only when needed.

14. When Agile is just not going down your throat.. and you are making decisions in your team.

15. When Agility is only for a brand new product development

16. When Agile is a way to hide your incompetence and quality issues

I asked my friend to revaluate WHY Agile.. and then decide to do Agile or not... Do you think it is a right suggestion?

Read More

Do you need Policing?

Today over a one on one session with Ani (One of our lead engineers), we(Me and him) ended up brainstorming an idea of code policing... In other words having policing efforts from someone on our code repository.... Of course the reason for such a thought and idea is to improvise the quality of the code that goes into our system... with all due respect to our hard working engineers, the quality of code is one thing that can tremendously increase your Technical debt...and something has to be in place that ensures that neither the quality dips nor the Technical debt increases...

So this idea of code policing... is it really a right thing to do? Do you think you need people who will go and check every line of written code to ensure that it is good quality? will this empower your engineers? Will this help improvising the knowledge of your developer community? Will this have a positive effect or will it create a process burden and forced quality on your teams?

Oh well these are not the questions I am just asking you.. these are the questions I am trying to find answers of for the last 1 hour 30 minutes... and the more I think over it the more I am convinced that POLICING SUCKS!!!!!

The moment you have to make hard efforts to keep a process running, believe me you are at the end of it... then be it a development process or a programming process... You definitely need to make efforts to ensure you have good quality [for product , for code, for team, for tests , for documentation for everything that links to you ] but then those efforts need to come from within... if they have to be forced you will have the need to police it to ensure they happen.. and when you feel the need to police it... that is the day you would want to go back and retrospect hard....

You need policing when

• You think that the quality is not coming from within
• You think that the efforts are not towards making things better, they are just towards finishing it
• You think you are trying to make it work this time and next time you would do it nicely
• You think it can be easily fixed LATER

And when these thoughts trigger you.... you dont need to initiate policing... instead

• Step back, March slow , Get your act together
• Read , Review , Read
• Stop everything for a moment, let people take time off from routine and get them to realize the maintainability havoc

So what do you think of policing? Do you need one?

Read More

Life of a Product - Where is the Quality

From the books of a Product...

I asked my developer to give me quality,

He wrote me a piece of code that raised my anxiety,

when I said this is not working as desired,

He said its just how the requirement was defined.. badly

I asked my QA to give me quality

He gave me a document that describes the resource scarcity

I asked on whether things work as desired,

He said it is in state of humility

I asked my Project Manager to give me quality

He gave me a list in the name of formality

I asked if that is how it was desired to work

He said it lacks a bit of stability

I asked my Product owner to give me Quality

He gave me a SRS that talks customer suitability

I asked if this is what the customer wants

He said We can change it later and totally....

A humble me, now walks the roads of feedback

Some people disown me, under the name of ability

A rejected I bounce back with features

The Sales claim its a product infidelity.....

Now I know what I am all together...

For some I am passion for others I am mortality

Where I work I am loaded with Money...

else I just come addon to other products as Charity...

--- A Poor Product

Read More

First get your errors right

Nobody wants to be in an erroneous situation.. I think if you ask 10 people 9 would say "No" to get into an error state at all. But believe me working in the IT industry for so long the reality realm of errors are that they are not very user friendly... Errors are just errors and the programmers argue that showing error stacks just help them debug the error more effectively [whatever happened to debug techniques]. Over last few months working on so many products and platforms I have learnt that the quality of your development is not really in how less bugs they have in the system [I dont deny the fact completely] but on how they handle those erroneous state.

"Your document is locked" is certainly a message but "Your document is locked by X user, Click here to message him to unlock or request a permission change or contact XXXX in case of issue" is much much better.

I believe that the errors that the end user see's demonstrate the quality of your product.. so a Fail Whale is always a better option than an "Unexpected Error" but if the fail whale really gives an information on what to do... would be worth.

An error like this does not help at all....

But a error message like this, can do the trick

So Dev? How do you show your quality of work? Just writing good is not enough... write better error messages.

Read More

The missing sense - Quality

The feature that you just delivered - if doesn't deliver a UVP is missing sense

The speech that you just gave - if doesn't motivate your audience is missing sense

The gadget that you just bought - if doesn't help you same time/money is missing sense

The post that you just wrote - if doesn't get a comment is missing sense

The video that you just posted on YouTube - if did not go viral is missing sense

The status that you put on facebook - if not liked by your friends is missing sense

The tweet that you posted - if did not get RT'ed is missing sense

If you are doing something and it is not triggering the right impact or effect.. it surely is missing the sense... The sense that everyone else calls Quality. People love quality, they simply adore quality... A simple concept that becomes Google is sense as it determines quality, a simple social networking tool that triggers a Internet revolution is sense as it shows a class, a quality.

Are you making any sense of what you are doing? Think... its time to do something that makes sense....

Read More

Don’t just be a “bargain” Guy?

We all bargain something or other, somewhere or else... we have learnt bargaining from our mothers, sisters, grandma’s, teachers, Bosses, colleagues and everyone else who we deal with on a day to day basis. You want your kid to wake up early for school he would ask for a toy, you bargain for a cheaper one. You drop him to school to study the teachers bargain for studies. You want him to be admitted to a school you bargain on price... Now as Software Engineers you face this bargain every moment..

Your Sales guy comes to you and ask for a feature, you bargain on time, he on dates.

You estimate your Project manager bargains on it

You give a Project plan your customer bargains on it.

An 80 yr old man who could not get out of the bed asked his 10 yr old to go and buy stuff from market. Since he was too young to shop, the grandfather told him “Bargain on anything that the shop owner offers”. Kid asked “what is bargain?” Grandfather said “If he tells you the thing is for 10$ you ask for 5$”. The kid went to a shop asked for a video game, the guy came back and showed him one. The kid said “I will pay 5 dollars for this”. Surprised with the kid the shop owner checked his price list found it was 4$ and he was still in profit said “OK, take it for $5” The kid thought for a moment and said “I will pay 2.5 for it”. The pissed of shop keeper said “take it for free”.. on this the kid said “then give me 2”

Everyone in this world bargains and when they bargain they bargain hard... But as Manager’s it is our job to balance the bargain. It is a need not a necessity so when we have to choose we can decide what and how much to bargain. Next time you sit on a chair where you have to bargain as an Engineer, Sales, Customer, Project Manager, CEO or CFO or anyone... bargain:

• On time that will not hurt Quality
• On resources that will cut cost but not Quality
• On schedules that will not hurt the burn-down status of your resources
• On commitments that will not affect your Teams plans and schedules
• On Plans that are over optimistic
• On technologies that can help you build a stable product than a faster product.
• On Quality that can let you sleep with peace

Read More

When Team is about Head Counts , Quality is a Grave

I am damm very upset. If getting 10 heads can achieve deliveries Quality is going to be under a 6 ft grave PERIOD. Yes and why not Heads dont form Team's so if Team's are on paper I am sure deliverables are just outputs and not results.

In an interview I gave a while back for a Unit Head for a reputed firm I was asked by a very Sr. Manager "How much do you care about Quality?", I answered "There are 3 mistakes in my resumes that you havent identified yet". I did not mean to say that you did not see it I meant that if you are looking for a resource to work in your organisation I am not the one, But if you want a associate to work along and add value to your firm You can look for me. Also the message meant that I definately care a bit more about quality than you do ;) Not the right way but your guess is correct that I never got a call back from there.

So the objective here is that Outsourcing has changed its meaning.... Its more about $ and heads than quality and softwares. This week I luckily happened to interact with a startup CTO who thinks else, he thinks that more and more startups are looking at building things fast paced and getting it ready for the markets than making sure that its quality coded. Since I promised him not to disclose his name he made a comment that "Its not how good a developer you are, Its about how fast can you develop it". Surprising? Well more and more startups work this way now.... I recently happened to another startup that has built another social networking product and just to the woes of Software development "A Javascript alert for testing remained in the delivery saying "Beta : Step 1"

Ok its 9:30 and I have to find my way back home so that I can stay up all night ;)

Read More