|
One of our team lead managers gave a talk about the Big Ball of Mud. With a title like that, how could I miss it? It was very tongue and cheek, but had a really good message about what we think of software architecture, the projects we work on, and the processes we follow and avoid. It was one of those kick in the pants presentations which encouraged enough engineers to think about how to improve our own software process, even after we thought we had a pretty good one going.
Living With The Big Ball of Mud I don't expect you to read all about the Big Ball of Mud, now, and you don't need to become an expert on it to read my blog entries. I think I need to reread it myself. The thing is, our projects do get complected over a period of time. It is so fun to work on three to six month projects and then forget about them. You get to deliver whatever you set out to do, often from the ground up, and you never need to maintain them. I've been in a few of them. Not only do you get the work done on time, but often you get thank yous from the boss, a night at a pub with all your project mates and their significant others, and you are slung into another sprint for another unrelated and cutting edge project. You want to talk about agile, this is where it's at! Then there are those projects which were started so long ago, you aren't sure if the first developers are still capable of remembering working on it. A meaningful architecture is no where to be found, and every new feature change requires a complete system regression test suite, if you have one, to understand its complete impact. Usually, your company makes most of its revenue on the big ball of mud projects and not on the go and throw away ones. So, the point of this blog is what the people I work with are doing to try the various processes out there to gain control over our own mud covered spaghetti projects. I am not going to say, here is a really great way of doing things, rather I want to be saying, here is what we tried, what we thought it would be, and what it we ended up doing. First Example: Better Code Review Process Example? I got tons, if you still have time. Here is one. Our team leads were saying we needed better code quality. I got together some interested team leads, and we talked once every two weeks about how we wanted to improve the quality of our code. Well, engineers are pretty smart, and decided that first, we need a good software development coding standards guide (SDM). It is pretty cheap, and once written, does something to unify the look and feel of the code, and lay down some team ground rules about what is and isn't allowed in the code. Then we talked about how to enforce the SDM. We talked about automatic tools like lint, we write code in C, C++, Java and Perl. We started looking at the Agile community. One thing that kept on coming up was the importance of peer reviews. Well, we had a review process, though no one did a code review in who knew how long. And perhaps no one ever did it effectively. Years ago someone wrote a code review process. It was based on the best information that could be found about the psychology of people and putting code first and personality last. It involved a lot of preparation and a coordinated review meeting. Some teams tried it a few times. If we had measured how much code was covered by the review process, it would be close to none. What was reviewed was changed so much by the end of the project, what was the review really worth? Most reviews, I think I can count them in my head, were really walkthroughs, which means educating team members on how the code worked rather then getting valuable feedback on how to improve it. So we talked about different kinds of reviews: formal review meetings, pair programming, informal and spontaneous reviews, and personal reviews. We talked about what was realistic, since no one was doing formal reviews. We came to the conclusion that the easiest thing we could achieve was spontaneous and unmonitored reviews. We would start with that, then we would explore other options once we got that going. I think I am going to leave this entry at that point. For now, you got a taste of my approach, and I'd love to tell more about where this all led.
Comments () |
 |
|
|
|
Tags:
blog,
Click to add your tags...,
|
Blogs 
