Week #9

This week I'm covering two different topics. On any normal blog this would be two separate posts, but I didn't think I could get you to click on two links. :) Another thing worthy of mention is starting to read Refactoring. A bit of the beginning was painfully simple and repetitive, but it's useful stuff.

TA vs Customer
The first part is inspired by the grading of the first part of the project and the conversation  that followed when we got our grades back. You guys may have seen the Piazza post about the discussion following the 11am class, and this is what it's all about (in addition to another conversation that happened). To give background, we were required to turn in an XML Schema as part of the first stage of our project. The best schema after the first stage would be chosen and the rest of the class would be required to use it for the remaining part of the project. At first, this bothered me because it hinders continuous design throughout the project. As we learn more, we aren't allowed to change a significant part of the project to improve the code or the final product that the user sees. But that's a completely different story. The issue that came up is that we got 6 out of 15 points taken off for not having ID/IDREFs in the schema. (some of these points will be returned)

It's a difficult thing to grade the design of a partially completed project. Different people think in different ways and therefore see different solutions. We saw a problem with having a schema that was too strict and didn't allow merging new data easily, so we created a weaker schema that used the names as informal ids. We still haven't found a clean solution for merging new data with ID/IDREFs present. The conclusion that we came to in the after-class discussion is that Peter is a very picky customer, and we have to do what he wants. If something is unclear, ask him and make it clear. As with many other things in the never-ending divide between academia and "the real world", a TA and a customer just aren't exactly alike.

1. The final product is more important than the intermediate.
When working with a customer, they shouldn't care that much about the intermediate steps, especially compared the the final product. I'm not saying they don't care about intermediate steps, it's extremely important to make sure that everything is going in the right direction. The final product simply carries more weight because it is seen by all the REAL customers. In this class, the intermediates are equal to the final product.

2. There should be more open communication between a customer and developer than what is normally acceptable between a student and TA.
If I were to walk up to my Automata TA with my homework in hand and ask him if it looked good, he would not go through every problem and tell me whether or not I was wrong and how he wants it. I expect the same from Peter. He isn't going to grade the whole project before he has to and tell me what's wrong. We can communicate with the customer through Piazza about problems that we discover. As with our schema problem, there are some choices the programmer doesn't second guess, but upon seeing the work, the customer would notice and conversation would take place. I'd like to think of the customer reviewing the  product as a further level of communication. We only get this further level of communication when we are graded, and the customer communicates back to us by subtracting points.

3. The customer usually only works with one team to create a product, not six.
Peter is the luckiest customer ever in terms of the resources he has. To complete a relatively small project, he has 31 engineers who have conveniently split into six groups. A customer in the real world usually has one team working on the project and doesn't have the luxury of choosing who has the best stuff. Projects aren't graded on a relative scale because there's only one team to build the project. Yet this project is being graded on a scale relative to what other teams do.

While the TA = customer comparison works to teach some aspects of open ended problem solving, it doesn't really encompass the experience of pleasing a Customer. I was hoping for a very-close-to-real-world experience with this project, and it didn't quite reach my high expectations here.


Joel Test
This guy who wrote the Joel Test is obviously familiar with the Microsoft environment. It's no secret, he mentioned it multiple times. After interning at three different companies (the first being Microsoft), I can tell that his views are very skewed towards the Microsoft, and more specifically slow release, way of thinking. I'm speaking from what I learned over two years ago, so a few things have most likely changed, but the background information I know is scattered throughout.


3.   Do you make daily builds?
Microsoft has long release cycles for many of its products. Office for desktop, Windows OS, even Internet Explorer. Some web products have daily releases, so you should be able build daily or else.
5.   Do you fix bugs before writing new code?
This section also has strong ties to Microsoft's slow release cycle. If you're releasing every day, you better have as few bugs as possible, because those bugs are all getting released.
8.   Do programmers have quiet working conditions?
This one reeks of a Microsoft mindset. For those of you who don't know, Microsoft mostly uses separate offices for every person. They don't believe in cubes or open work spaces. It seems kind of awesome to have your own office for a while before starting to recognize the downsides. Open work spaces promote communication on more levels than just "how do I do this thing I could search", and open communication is important for reason explored in XP as well as other social aspects. When you have offices with doors, you're also less likely to ask questions that should be asked, and can only be answered by other people working on the same project. Without asking questions, the whole process of development moves slower. While being interrupted sucks, the example used in the paper can be eliminated by people knowing when its the right time to ask a question. You have to be aware of the trade off, but sticking everyone in an office is not the only solution.
9.   Do you use the best tools money can buy?
I chuckled when I first read this title. Because it said "buy". More and more companies are getting into the habit or not using the best tools money can buy, but using the best tools they can make. Then once I started reading, I realized they weren't really talking about software tools, but mostly hardware. So for hardware tools, I would agree. Dual monitors are the best, that's why I have one at home. I knew someone with 24GB of RAM to build faster. Give people the hardware they need when they need it. But when you start branching into the software end... as they mention Paint... the best tool that money can buy for imaging software used purely by developers is probably GIMP. And tada, it's free. You venture into subversioning software and bug trackers, build systems, and the like. At a certain point, the big tech companies start to make their own, and I'd be surprised if Microsoft hasn't started to do the same. You do this well, and it has even greater positive impact on productivity than any hardware could.


Overall, all of the Joel test rules do apply to good software teams. You just have to be familiar with where he's speaking from, and take a few of them (the last two I mentioned) a bit less literally.

BTW, you're a trooper if you actually got the end of all this ranting.