yearly review. The project we are still working on was originally planned to be released in April, 2007 and, I assume, the review was postponed because the project was late and they probably thought doing the reviews then would have made it even later. Well, NOT doing the reviews may have been the problem because we're still working on the project!My review went well, by the way. I'm doing OK. Not stellar but they're not going to reprimand me. We talked about how the last year has gone but also about upcoming projects and where I fit in with them. Part of the problem is that so much of the work sounds so interesting, it is hard to decide which projects to be considered for. We also talked, in general, about how difficult some of the aspects are of the various projects. It brought up two points I had just been thinking about while reading one of the recent Joel on Software articles. The main point of the article was that projects that have a lot of problems to overcome are the ones that are best to do. That is because if it was easy, it would either be worthless or everyone would be doing it. The more difficult the project is, and if you can overcome the difficulties, then people will be happy to buy your product because you'll be helping them do something they didn't think they were going to be able to do.
Another point was that the areas of any project that are the most difficult are the ones you don't have control over. Their point was that it was more difficult to produce a program that runs on the customer's hardware and not on your own hardware (servers) that you control. The question you have ask is how do you get control of those difficult aspects? One method is to limit the types of hardware your product will run on. Another way is to make sure you have as many types of hardware for testing.
I'm writing this without thinking about it much. Maybe I'll get a chance to write more about this in another entry.
No comments:
Post a Comment