NO! You can not sing my song!

According to this slashdot post "music licensing companies are now hitting small bars and coffee shops that offer live music, even if only occasionally and even if the musicians don't get paid. One coffee-shop owner told musicians they can only perform their own songs from now on." It quoted the news saying that

"A restaurant owner who doesn't even offer live music was approached for payment for having the TV on while the Monday Night Football theme played. And if the owners pay up to one licensing company, all of the others start harassing them, calling four times a day, demanding payment too. It sounds like they don't even check whether any copyright violations occurred, they're just sending bills to any business that may or may not have live music."

Now, that's just getting out of control. And when you are talking about stupidity and greed. Look no further, this is THE example of both. To make things worse, there is another news from YouTube, they were forced to take down one person's guitar lesson videos (that is more than 100 of them) because "one of the songs that he taught was copyrighted". For God's sake, that's just one song that was copyrighted. Plus this guy may have bought the CD for that song or sheet music for that song.

Now it makes me wonder, if things like these keep happening, will it one day become illegal for people to sing a copy-righted song in public space? I enjoy listening to a guy busking around the corner of the street where I am working. Does it mean, one day RIAA will come to this guy and say "Hi dude, you have to pay us, coz you are singing a copyrighted song.". If that ever happens, I have only one word for it. The word will start with the letter after "E" in alphabets.

I remember when RMS gave a speech about GPL back in the 90's, he said that if copyright can not be stopped, one day people will be charged every time they read a book, or lend the book to someone else. Or they have to pay everytime they boot up a computer ... etc. These haven't happened yet, but looks like the music industry has started charging people for singing "their" songs. Just how far those people can go ...

Powered by ScribeFire.

What went wrong with "THIS" project.

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.

Powered by ScribeFire.