Have you ever been on a project that has been written with more layers than a Wall's Vienetta and one of those layers is a wcf layer even though its on the same box? And with millions of design patterns?
And guess what, the user base is like 30 people max!?
Its crazy, I been on so many projects like this. I think its actually more due to the willingness of the developers to do 'best practice' and super duper martin fowler patterns than the reality of what is appropriate to the requirements.
Friday, 4 February 2011
Saturday, 29 January 2011
Estimates
Estimating the time it will take to code something is not easy, it takes experience and also the opinion of more than 1 person. I worked on a project once and I had to code a piece of work that was estimated by someone else - at 10 days. It took about 60 days in reality. Although I was new to the technology, it was still severely underestimated.
How best to avoid such situations? Ensure that you don't just rely on 1 person's opinion. Track a persons' opinion, so over time you know that person A tends to overestimate or person B tends to underestimate. Of course if it was a group exercise (which estimating should be) then this is less relevant.
Agile does this with various methods, but the main thing is that estimates are a team effort not relying on 1 person and that estimate accuracy is tracked and the feedback from that is fed back into the estimation process. In fact this is just common sense.
Amazingly, more often than not this does not happen.
How best to avoid such situations? Ensure that you don't just rely on 1 person's opinion. Track a persons' opinion, so over time you know that person A tends to overestimate or person B tends to underestimate. Of course if it was a group exercise (which estimating should be) then this is less relevant.
Agile does this with various methods, but the main thing is that estimates are a team effort not relying on 1 person and that estimate accuracy is tracked and the feedback from that is fed back into the estimation process. In fact this is just common sense.
Amazingly, more often than not this does not happen.
Friday, 28 January 2011
Requirements
I was on a project once where the requirements gathering phase was completely missed out. Instead, departments just wrote down raw requirements on a Sharepoint list, however ambiguous, and that was it. There was no analysis, to nail down requirements and non-functional requirements into formal user stories, priority, for sprint 0 [agile] or a formal functional specification / technical specification [waterfall], use cases etc. We was just expected to create a system from that, to a deadline (don't know how that date was arrived at) obviously incredibly difficult. A lone tester was brought on to the team late on and its just started to dawn on the team and the manager that its going to be impossible to test without use cases or documentation on how the system is supposed to work. This wasn't the only thing that wasn't right but let's just stick to the topic of requirements. Looking back now I should have raised this earlier on but even I joined at a far too late stage, and realized far too late, and I just got down to trying to do what I was told, trying to fit in with the team, on the piece of work in an incredibly difficult subject.
It's amazing but true.
Lesson 1: Fully understanding and capturing as much requirements as possible in documentation (in whatever form) is essential - and getting them 'signed off' from the business.
Lesson 2 (to self): Always believe that process is important, and trust your experience, and don't get overwhelmed by the organisation to think at the start 'oh it must be ok because this is how its done here'. If it looks like a duck and quacks like a duck - its a duck.
It's amazing but true.
Lesson 1: Fully understanding and capturing as much requirements as possible in documentation (in whatever form) is essential - and getting them 'signed off' from the business.
Lesson 2 (to self): Always believe that process is important, and trust your experience, and don't get overwhelmed by the organisation to think at the start 'oh it must be ok because this is how its done here'. If it looks like a duck and quacks like a duck - its a duck.
Friday, 6 February 2009
KISS
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.
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.
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)