"highly irresponsible, sloppy test to rate the quality of a software team".
So I have decided to rate my project base on his criteria.
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
1. Do you use source control? YES
Yes we do, we use primarily svn.
2. Can you make a build in one step?
Yes at least for our web stuff. We use ivy to manage our internal libraries dependencies and ant to build all the java stuff. The rest of the libraries (namely 3rd party like spring and hibernate) are checked into svn. The reason being these are the libraies most unlikey to change, unlike our own internally developed libraries.
3. Do you make daily builds?
Yes, we use cruisecontrol as our countinous integration server which polls our svn server for code changes and attempts to build them. The only problem is we couldn't get the jabber plugin to work so we rely on cctray for notification.
4. Do you have a bug database?
This is where we got the first NO! Nope we don't have a bug database. So far we have been programming for about a month. But at our current stage we are still trying to figure out what extjs can do for our ui even as we are developing parts of the backend and parts of the thick client version. Although we have bugzilla in our development network but the problem is that none of the developers gotten around to learning it yet. So even if we have bugzilla no one is using, gotta get up to speed learning about bugzilla for the whole team. Might just decide to install Trac as I think it might be easier and it has integration with svn.
5. Do you fix bugs before writing new code?
I would like to think that all my team members do. But we are currently still trying to learn and evaluate the software/libraies that we are using (some GIS cots and some new libraries).
6. Do you have an up-to-date schedule?
Yes we do, in terms of when to deliver the project and the important milestones. But in terms of estimating how much work we can do and the accuracy of that estimate we are not quite there yet.
So we actually have to try and gauge how much work there is and how much effort is required. We are currently trying to use story points as a guide and using this month (the first official month of coding) to try and see how many story points can we actually complete since we are using a couple of new tools/libraries (extjs and spring mvc). And from there we will know roughly how much work we can do.
7. Do you have a spec?
Joel in his article mainly refers to Functional Specifications. Hmm this part we are also not too good. For the current project what we did is to work through the user workflow (or what we know of the work flow) and the user/operational requirements and try to think off what features are in thhe system based on our interprtation of the user requirements. This is so that at all times we know roughly what we are going to build. And also as we interact with the users we can get them to confirm whether the features are needed or not. The project complexity comes from having to interact with many branches/division in which they have different requirements, feeding it back to the manager commission the project so that he can have the feedback and make the necessary decisions.
And we taken these feaures/operational requirements to try and design a workflow and try to see how the users will interact. Basically we use a big whiteboard and draw out scenarios and simple screen shots to determine how the user will interact.
We then transfer these drawings to paper and file it for reference. What we lack is the transfer of the drawings to words specifications. We have no functional specification templates and probably will adopt Joel's as a starting point to see what needs to be included.
The main problem is that the project is on a rather short timeline and the developers are the ones who are coming out with the design, documenting and code at the same time. With the short timeline we have it's why we work off sheets of paper with drawings and notes and not write formal specifications. We don't really have a program manager (as in Joel's version of it) to help us come out and write the functional specs.
But what we intend to do is to come out with small working systems like what agile methodologies advocate (Currently we are trying out SCRUM) to continuously get the users feedback to help in designing and specifications.
So will we write specifications? Probably yes as we do need some sort of documentation to drive things like testing and user docs.
8. Do programmers have quiet working conditions?
Yes we all have our own cubicles.
9. Do you use the best tools money can buy?
When i first joined my current company all I had was an internet laptop and a development laptop that has no internet on it. They have strict policies on having the internet on the development network. It was a nice laptop, 17" screen, Core 2 Duo and 2Gb of ram. Unfortunately I was transferred to another project and all they could give me was a 14", Pentium M 2.4 and 2G ram.
I do agree with Joel that we need to give the best money can buy and that means trying to max out the ram (we used WinXP so that means about 3gb to 4gb would be nice) and having real monitors. Why? Imagine on the 14" machine I run Oracle Xe, Tomcat, Netbeans, Eclipse. And to program using a small screen is really a pain, especially when doing javascript. It does gets abit tiring scrolling the screen up and down. I tired to run Workshop for Weblogic 10.3 and immediately my laptop starts to page really badly, I checked the preformance tab and it was using 2.3gb of memory, so I was trying to swap about 300megs. And when you are debugging you need to see the code and watch the varibles a 14" screen quickly runs out of space.
Well my current setup is a quad core xeon, with 3gb and a 19" real monitor. It could be better with another 19" monitor to aid in debugging and reading javadocs or other documentation.
10. Do you have testers?
No, in our setup we don't have a testing group dedicated to just doing testing. Most of the time the developers are the testers. Although we do have a QA group that does security and vulnerability assessments.
11. Do new candidates write code during their interview?
Before I got a job, I went for 3 interviews, two didn't ask me to write code, my current company was one of them. And the one that asked to write code, did more than that, they made me do binary math, made sure I knew what XOR, OR and AND were, draw on a white board how I might implement some things in code. But then of course I chose the company that I had more interest in.
After I was in the company for about 2 years, I attended two interviews with fresh graduates with my project manager, to assess who should join my current project. I did have a dilemma on whether I should just base on paper qualifications and not ask them do any coding just as I have gone thru. One of them was clearly out as he is a Computer Engineering graduate with mainly hardware experience and I was looking for a software kind of guy to do web programming. He has no knowledge of what an app server or even what J2EE is, so i dropped him. The second is a computer science grad from the same university that I come from and he does have some experience but I did not ask him to write code as there were other project managers around me and they were all asking the normal questions like, "Tell me you last project" and so on.
I feel that asking the interviewees to write code is important, it demonstrates at least a certain sense of logical thinking and more than being able to write code, the person should also be familiar with design patterns, general OO concepts. He/she dosen't need to be an expert but should realised such things exists. For someone who dosen't know what encapsulation, inheritance and polymorphisim is, you probably gotta spend more time training him and bringing him up to speed.
When doing the interviewing, I have to think about my team members who are already working on the project. Do they have the time and energy to try and hire someone who has little experience and knowledge, and bring him up to speed with what we are doing? In the book The Mythical Man-Month, the author talks about how adding people to a project actually makes it slower. In , Software Projects Secrets, programmers are always using some new toolkit or new framework or some new component with each new project. For the people who sort of know the job, it is hard enough to learn on the job, imagine someone who don't really know and have to pick up all these knowledge and more! And remember the project moves at the speed of its slowest member.
12. Do you do hallway usability testing?
No, in fact I don't really remember anyone doing it. I do think its a good idea to do some user interface testing using your fellow colleagues.
Final Score
Yes: 6
No: 4
Maybe: 2
Hmm there are 2 maybes in the "Do you fix bugs before writing new code" and "Do you have the best tools money can buy". I can't really gauge the first due to the project starting and we don't really keep tracks of the bugs and the second is because we could have requested for more money to buy another monitor but because we didn't cater the money for the extra monitor so it's mainly due to our own fault.
So according to the score my project got less than 10 and so my project is due for some serious rethinking on how to do things properly.
No comments:
Post a Comment