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
0 comments:
Post a Comment