I am going to talk about "this project".
It is a project I worked on as a senior developer, then a technical leader. I liked it a lot. It seemed to me a perfect project to work on at the beginning. The architecture was good, the architect team has some of the best developers I have met (one of them is behind a major OS Java tool). There was a dedicated and very professional BA team, a dedicated UI architecture team, who defined the user interfaces (screens). There was this configuration team, who looked after the business process and they really understand their business very well. The project manager was a lovely bloke. Few days into this project (that is before I started doing anything for real), I thought I would be working on a dream project (especially after worked for a government agent for few years doing ...not much).
However, after less than one and half years on it, I decided to call it off and left the project. Admittedly, I have learnt a lot in this project, especially from the architect team. But at the end of the day, the most important thing for a project is always to deliver. You can lecture any client with your heart out about how elegant this project was designed, but if you can not deliver, the client will show you their fingers. With this project, the thing (I can not call it a product, without looking down my toes) we managed to deliver is not what we had in our mind. Mind you, the end result was not hopelessly bad, but it was bad. At one point, we were fixing more than 250 defects a day. Yes I admit that a proportion of those so called defects are things like typos, UI being not exactly the same as defined in MS Visio, but the majority of them were real defects. Misunderstanding of the business requirements, not enough validation against user input, missing functionalities as required ... we delivered the project to system integration test(SIT) team 6 moths after we started coding, then spent about 10 months patching the system up. Yes, I am not kidding, it was that BAD.
So, it made me think, why so? Why an almost perfect initialized project went so wrong? What caused the mischief and how things could have been done better? And here is my two cents I'd like to share with you guys.
1. Communications broken cross different teams.
We had a good architect team. Unfortunately, this was a very quiet architect team. Most of time, we little day2day developers wouldn't have a clue what those guys were up to. They put most of the stuff they do on a project wiki. Fair enough, you can find everything (almost) you need about the system on the wiki. But they are not updated frequently. And if the wiki was so important to the project, I had to say that the importance of it was not well communicated to rest of the team.
The foundation of the project was well defined/designed, but I only found it out by spending my first few weeks with this project doing nothing but digging into code everywhere trying to figure out how things were hooked up together. If I was given a well written document, or some kind of induction on the architecture of the project, it would save me a lot of time and frustrations. Because there was no such document and induction, various people (with various level's of experience) will see the application in various ways. The result .... a very well defined foundation, a lot of messy components, a lot of duplicated code. Because people didn't know that things were supposed to be done in a certain way, and a lot of tasks have been looked after by the framework. I remember at one time, there are 4 different StringUtils classes, and a number different ways to convert a Date to String or vice versa. Another time, a team member complained about how he by-passed the layered architecture (which is what made the foundation of the project) to do something really quickly ....
Communication was also broken between the BAs and the UI team. At one stage, I was given a UI design document and I could not make sense out of it. So I called for a meeting, when I gave this UI document to the chief BA, he had a look and said "This is crap!" ... so, it was crap, then why didn't these guys check it before giving it the development team? We had a lot of defects related to missing functions, most of them came down to things were not possible to implement with the UI design.
2. UI driven development ... bad.
In any software project there should be a Bible like document, where a developer can find clearly defined business requirements. In this project, Bible came as a large set of pretty Visio diagrams known as the wireframes. Each of the wireframes also contained a lot of comments, which was supposed to define the function of the screen. This arrangement worked fine for the first release which contains just a few functions. As the application grew, this arrangement was not adequate enough. Actually, in my opinion, for any business component whose function is more than just data entering, there should be a dedicated document for it. In this project, there was a business requirement document. But because it was written in such as way that it was almost impossible to link things there to things on the wireframe, not many people read it and for these who read it, it was more confusing than enlightening.
The result of this arrangement was that we developed a pretty looking application and only to find a lot of missing functions during SIT.
-- There are few other things I'd like to talk about this project, I will put them in another blog. So to be continued.
It is a project I worked on as a senior developer, then a technical leader. I liked it a lot. It seemed to me a perfect project to work on at the beginning. The architecture was good, the architect team has some of the best developers I have met (one of them is behind a major OS Java tool). There was a dedicated and very professional BA team, a dedicated UI architecture team, who defined the user interfaces (screens). There was this configuration team, who looked after the business process and they really understand their business very well. The project manager was a lovely bloke. Few days into this project (that is before I started doing anything for real), I thought I would be working on a dream project (especially after worked for a government agent for few years doing ...not much).
However, after less than one and half years on it, I decided to call it off and left the project. Admittedly, I have learnt a lot in this project, especially from the architect team. But at the end of the day, the most important thing for a project is always to deliver. You can lecture any client with your heart out about how elegant this project was designed, but if you can not deliver, the client will show you their fingers. With this project, the thing (I can not call it a product, without looking down my toes) we managed to deliver is not what we had in our mind. Mind you, the end result was not hopelessly bad, but it was bad. At one point, we were fixing more than 250 defects a day. Yes I admit that a proportion of those so called defects are things like typos, UI being not exactly the same as defined in MS Visio, but the majority of them were real defects. Misunderstanding of the business requirements, not enough validation against user input, missing functionalities as required ... we delivered the project to system integration test(SIT) team 6 moths after we started coding, then spent about 10 months patching the system up. Yes, I am not kidding, it was that BAD.
So, it made me think, why so? Why an almost perfect initialized project went so wrong? What caused the mischief and how things could have been done better? And here is my two cents I'd like to share with you guys.
1. Communications broken cross different teams.
We had a good architect team. Unfortunately, this was a very quiet architect team. Most of time, we little day2day developers wouldn't have a clue what those guys were up to. They put most of the stuff they do on a project wiki. Fair enough, you can find everything (almost) you need about the system on the wiki. But they are not updated frequently. And if the wiki was so important to the project, I had to say that the importance of it was not well communicated to rest of the team.
The foundation of the project was well defined/designed, but I only found it out by spending my first few weeks with this project doing nothing but digging into code everywhere trying to figure out how things were hooked up together. If I was given a well written document, or some kind of induction on the architecture of the project, it would save me a lot of time and frustrations. Because there was no such document and induction, various people (with various level's of experience) will see the application in various ways. The result .... a very well defined foundation, a lot of messy components, a lot of duplicated code. Because people didn't know that things were supposed to be done in a certain way, and a lot of tasks have been looked after by the framework. I remember at one time, there are 4 different StringUtils classes, and a number different ways to convert a Date to String or vice versa. Another time, a team member complained about how he by-passed the layered architecture (which is what made the foundation of the project) to do something really quickly ....
Communication was also broken between the BAs and the UI team. At one stage, I was given a UI design document and I could not make sense out of it. So I called for a meeting, when I gave this UI document to the chief BA, he had a look and said "This is crap!" ... so, it was crap, then why didn't these guys check it before giving it the development team? We had a lot of defects related to missing functions, most of them came down to things were not possible to implement with the UI design.
2. UI driven development ... bad.
In any software project there should be a Bible like document, where a developer can find clearly defined business requirements. In this project, Bible came as a large set of pretty Visio diagrams known as the wireframes. Each of the wireframes also contained a lot of comments, which was supposed to define the function of the screen. This arrangement worked fine for the first release which contains just a few functions. As the application grew, this arrangement was not adequate enough. Actually, in my opinion, for any business component whose function is more than just data entering, there should be a dedicated document for it. In this project, there was a business requirement document. But because it was written in such as way that it was almost impossible to link things there to things on the wireframe, not many people read it and for these who read it, it was more confusing than enlightening.
The result of this arrangement was that we developed a pretty looking application and only to find a lot of missing functions during SIT.
-- There are few other things I'd like to talk about this project, I will put them in another blog. So to be continued.
Powered by ScribeFire.
No comments:
Post a Comment