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

Why Yammer works!!!

A few months ago we ignited a YAM into our system, a system where collaboration was key.. we had our development Team split between Pune, Chennai , Brentford, Wales, SFO and our product teams split in Germany, France and US. You can imagine that with such a distributed development Team it is not easy to manage effective communication and collaboration. Forget about effective at certain times even communication is not easy...

Yammer came to be a respite to our Team.. A microblogging platform, that works for your organization, has a set of handy apps to help you effectively use it at the same time has a cool set of Integration. Though we havent found ourselves to be the spamming users of Yammer we have definitely seen ourselves to be using it effectively.

Now no matter where our Team are we tell each other :

1. What we are doing

2. Where we are stuck at any point of time

3. We share some special Team moments , some announcements and sometimes even jokes and laughs.

4. We now know what our colleagues are doing

5. We know where they are stuck

6. We now have an easy way then sending an email and waiting for X person to respond.

7. We found a way to YAM now instead of asking someone to ask someone to ping someone...

Yammer is really effective and helps collaboration smoother and in easier way. There are Desktop clients for both Linux and Windows that let our developers across platforms use it. We got Black berry client for it, we have the browser version for those who dont want there CPU leaks to such apps, we sometimes switch to twitter and put a #yam to keep our Team in touch.

In the last few days we are using Groups effectively. So within the organization various groups like OPS and Project Teams now use groups to update. We now intend to use communities effectively where the Idea is to bring the Customer Services , Sales, Operations, Marketing everyone involved under different communities.. this would make them more collaborative and give more visibility of what is happening around.

How to set Yammer for your Team?

1. All you need a valid domain and email address on the domain to start with.

2. Visit www.yammer.com

3. Create a Organization with your valid email address.

4. Receive an invitation and confirm.

5. Fill in your Profile details as in Age, Sex etc.

6. Invite other users with the email addresses that are on the same domain, wait for them to join.

How not to fail Yammer for you?

1. Keep on updating it.

2. Chat , Interact do not spam.

3. Use the apps and tools like gtalk integration, RSS feeds , BB app, Desktop app as you surely would not use the browser version for very long.

4. Dont be a spectator. Be interactive.

5. Yammer is not to monitor people. It is to interact with them. So if you are a manager use the tool to involve.

6. Share , Share and Share

Well if you are a development Team, Distributed .... You surely gonna like this.

Yam baby Yam.

Read More

Where is your SWAT Team?

2001-02 While working with the organization I was working then, We faced a very critical issue. We wanted to work on a stronger road map for the product then and were always back pulled by issues around the smooth execution of the production systems, customer issues and rants etc etc. Every time we started working on the development windows we were pulled back either by down times or customer requirements , issues.

This hurts the road maps always and badly. A new feature would be compromised to an issue that the customer wants urgently. We killed almost a few important months of your roadmap that ways. The moment it was decided to have a dedicated Team to handle such issues... We formed a first unit of 2 Development engineers, dedicatedly working on critical day to day issues. Issues that were raised by customers and were urgent. Issues that needed quick response. Effect was, in 3 months time we were able to add up things that we were not able to get in 1.5 yrs.

The output was clear.. A dedicated Team working on second line issues and customer client issues is always a gem. Very Very High ROI.. because the Team actually sets to become the domain experts due to the variant area exposures.

We did the same thing in the organization we worked, in times of high delivery pressures and low Team sizes.. The SWAT Team we named it after (Special Weapons And Tactics). All through the last few years it has helped us balance our Teams and resources and Knowledge about the product. To that matter even the Trainees got to become the member of SWAT and got control on the product. we made our mistakes by pulling people from main stream development

Now this was us. How about you?

Do you shuffle your resources from your main stream Teams just to get some immediate issues resolved?

Do you focus on customer immediate issues than product future?

Do you compromise critical features for urgent customer issues?

Do you believe that your development Team produces much slower than it should?

Do you believe that your velocity is bad?

Well if any of the above questions go in a YES, Boy think over and find where your SWAT Team is.

Such a dedicated team to support urgent issues helps the product move forward. It is always in my experience that when development teams are shuffled in tasks it kills creativity , performance and of course above all the frustration that the teams face juggling tasks and work every other day.

If you dont have one .. Go find your SWAT Team

if you got one and abuse it ... Reform

Read More

Cartoons are the Best way to convey

I thought I would start my own series to present what I want to say in the 50 line blog posts

this is first in the series

Read More

Project Management - The Developer's Productivity Guide

Not much of my time is really spent on pairing with the developer for production development but I do spend some time howering around them for Business clarifications and other petty things.. For the last few days when I was really trying to understand the areas where the developers loose most of their time and the reasons for the Iterations not being enough to finish the features that they are working on, while I was trying to find all these things I really came across a strange thing...A Lot of foreplay and playoff happens when they are on the RAD tools doing the production development...

While me and Kari (My Boss) discussed about effectively using the RAD tools for development specially when we saw the way Savio (Our Tech Lead) organises them, it was something that we wanted our guys to really work on, however I see something more major here in terms of the productivity... ofcourse organising the development window is going to help but what about other things ? Imagine you have to continously refer to a Wiki page or to the Bug Tracking tool ? Or the Web Server Logs ? or the constantly buzzing PM who wants update from you on the IM window? Or your Sweet Heart who is the inspiration to you when you develop something ... or to that matter your Online date you were just hitting on in Orkut?

Yeah so the reason I say all this is that I see lot of toggles of windows when you are working be it any of the above or something not here... I would say in a whole 8 hr work period you would actually spend toggling windows and changing and switching and searching things for atleast 1 hr... You may for sure Disagree ... But on my Blog you are allowed to lol. So the conclusion is why dont we provide the developers with a 21 inch monitor .... or a more huge monitor so that the developer can really see lot of items in one go... (I am not in favour of changing the font size to the lowest to make this happen). So if you really have a huge monitor 21" or more it will for sure make a difference. On the other front the cost of the monitor is not so high (7000 INR + the 17" monitor we buy).

Though I agree that it wont increase the productivity drastically but the developer productivity will certainly be improved... what do you Industry experts say? While I prepare for the next Hurdle in the Developer Productivity?

regards
Sameer Shaikh

Read More