Tester or Noisemaker
Nick
Malik has an intersting post about Testers and Noisemakers.
I like this post because it really hits home for
me. In my tiny development group, we don’t have any testers.
Therefore I am the perpetual noisemaker. I challenge every bad design
(which is most of them). I challenge every line of source code I see
(which is very few of them). I drive my team lead crazy. I try to
make our software “better”. But in my eyes, no one else sees the benefit
of writing better software and using better designs. The team has the
unfortunate property of cowboy style development being OK.
In this case I don’t view any such challenges to
the “bad things” as being CLM. Rather if it does limit my carreer, then I
am better off for it, as this is not an environment in which I wish to
work. Of course, I am not working at Microsoft like Nick. Keep
fighting the good fight Nick. Make Microsoft’s software better! God
knows there is plent of need and room to do that.
November 13th, 2006 at 10:37 am
[...] Introducing a culture of code review I got a ping-back from another blog post written by Jay Wren. He mentioned that his dev team doesn’t have a ‘test culture’ so he has to play a ‘noisemaker’ role when he is challenging bad designs or code. I read with interest because, to be fair, code review and design review is not usually done by the test team. Functional testing is usually where the test team really digs in, although they have a healthy input in other places. Designers need to ‘test’ the design, but this is most often done by having the architect create high level designs and having other team members, including other architects, review the design. This is, far and away, the most important ‘test’ of software, in my opinion, but is too rarely done, especially for code that is written for internal use as most IT systems are. Frequently, there is no architect available. Even if there is a senior person available who can play the role of reviewing architect, what process would they follow? I’d suggest that any company in this position investigate the ATAM method from SEI. This is a way of evaluating a design from the standpoint of the tradeoffs that the design accounts for. Essentially, the concept is: each design must serve the purpose of meeting functional requirements, organizational requirements, and cost/complexity requirements. By reviewing first collecting and prioritizing requirements for reusability, scalability, maintainability, and other ‘abilities’ (called system quality attributes), you can then evaluate the code to decide if it is ’scalable enough’ or ‘maintainable enough’ to meet the needs. This allows a realistic review of a system. It takes a lot of the ‘personality conflict’ out of the equation. There is no perfect software system. However, if a system’s design is a good match for the requirements of the organization that creates it, that’s a good start. Published Monday, November 13, 2006 7:26 AM by NickMalik Filed under: Project and Program Management, Enterprise Architecture [...]