Keep it simple stupid. Often said, butnot very often implemented. What does KISS mean?
It means dont let your code get overly complicated and make sure everyone in the team is at the level of code profieciency so that they actually understand the code.
For example, design patterns are great. I love them. But if you dont make sure everyone in the team and company understands what they are, theres pretty much no point doing anything fancy. Because no one else will understand it -when the project moves on. The original developers may have moved on, left the company etc. If no one else understands it, when it comes to phase II, some developer will look at it and hack around it because they dont understand it. Now there are 2 different ways of doing the same thing in the code.
So what my message is to keep everything as simple as that every developer understands whats going on.
Friday 6 February 2009
Thursday 5 February 2009
Beware of Gurus
Theres one in every IT department. You know the ones. They know everything, they say the right buzz words, sound confident in what they say. They sometimes save the day by working late and fixing a live bug. Management love them because they are so confident, they are reassuring. This guy knows what his talking about.
Problem is that they like working on their own. They do everything without involving anyone else. They go off on a tangent and redo the whole code without talking to anyone about it. Thats the problem. They tend to write technically, rocket science code, that seems impressive - but no one else understands it. Theres no point writing stuff that only one person understands.
Its better to have people who talk to each other, are good in a team and get consensus on writing code, which is a team effort.
So beware of Gurus. Get team players instead.
Problem is that they like working on their own. They do everything without involving anyone else. They go off on a tangent and redo the whole code without talking to anyone about it. Thats the problem. They tend to write technically, rocket science code, that seems impressive - but no one else understands it. Theres no point writing stuff that only one person understands.
Its better to have people who talk to each other, are good in a team and get consensus on writing code, which is a team effort.
So beware of Gurus. Get team players instead.
Continuity of Care
In the health profession, there is the phrase 'Continuity of Care'. It means that whenever the carer of a patient is changed, the level and care remains the same.
In IT projects, all to often managers and team leads change, team members change. It is essential that the same level of care of the software is maintained. By this I mean that the same architecture, vision, and passion is maintained in the code, and that this is successfully transferred when team leads change.
In projects I have seen in the industry, in fact the current project I am on, all too often a project is a muddle of different ideas. There was no continuity of care when team leads changed. Different ideas resulted in various different architectures in the code, half baked ideas and half - half code where one bit of code is being changed to a new way of doing things, but hey guess what the contractor didn't finish the job and now there are 2 different ways to do the same thing. Standards are not maintained. No code reviews happen.
Whenever someone on the team changes, especially the team lead, remember to ensure that the new guy understands the architecture and follows through keeping the code consistent.
In IT projects, all to often managers and team leads change, team members change. It is essential that the same level of care of the software is maintained. By this I mean that the same architecture, vision, and passion is maintained in the code, and that this is successfully transferred when team leads change.
In projects I have seen in the industry, in fact the current project I am on, all too often a project is a muddle of different ideas. There was no continuity of care when team leads changed. Different ideas resulted in various different architectures in the code, half baked ideas and half - half code where one bit of code is being changed to a new way of doing things, but hey guess what the contractor didn't finish the job and now there are 2 different ways to do the same thing. Standards are not maintained. No code reviews happen.
Whenever someone on the team changes, especially the team lead, remember to ensure that the new guy understands the architecture and follows through keeping the code consistent.
Subscribe to:
Posts (Atom)