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.

Week #8

Looking at the viewing statistics graph of the blog amuses me. The only people who do read look at it right when it's posted. It's good to know some people are reading what others write, even if it's relatively few out of both classes. You guys are the best. :)

I don't really have anything to go on about this week. The test was not my favorite. I didn't put down my best work. The haskell problems were by far my least favorite because of my inexperience with the language. Oh well, what can you do?

Another one of my least favorite things is UML. I have never seen it used anywhere outside of a Downing class. After talking to someone, I realized it's a bigger thing in companies that aren't all technical so it may not exist in my tiny little ecosystem, but it has a bigger part in the rest of the world. Between non-technical people and technical people, it creates much better understanding.

I was looking at piazza to see if the class schema has been decided, but sadly, it wasn't. :( It's kind of a blocking issue to continue with the project, so it would be nice to have that, but I guess we don't really need to be starting with the project yet. I did run into the awesome post about someone getting an interview from Google because of blog posting. Software Engineering and OOP are classes that Google should love because of their relevance to everyday work. Personally, I think that OOP has helped me on my career path more than any other class. Besides helping with interview questions, it taught me C++ which I used during my internship, which ultimately resulted with me getting a full time offer. THANK YOU, DOWNING! :)

Week #7

Time is flying by. Already week 7? Already project 4?

I wanted to spend this week talking mostly about design. Design in something that seems hard to master, and on top of that, we don't get very much practice with it in school. I'm sure there are some good books on design out there. If you happen to know any offhand, I'd love to know the names. The project has taken up quite a bit of time so far, and I don't think it will let down much, but it's good to know a good book to read when I get the time for it. From the reading next week and the whole basis of the book Refactoring, I assume we will be covering more about design, and that would be freakin' awesome. (and I'll add another post as I get less stupid)

In school, we don't have much experience with designing large and complex systems. This project is the largest and most complex thing I will probably ever create in school unless something suddenly appears next semester. The runner up would by the final project for CS345 where my partner and I created a language that was a combination of Prolog and Jython which made for an... interesting... language. Still, the greater point is that we don't really have much design to think about. Jython does have a large codebase that you can learn about design from, but I'm sure many just found where the code needed to be changed and ignored anything else. Every other project during school has been basically like "oh it outputs the right answer usually from one file and the code looks reasonable? awesome". We just don't get to organize ridiculously complex code bases in school.

My experience with design in internships has been lacking also. Two of my internships involved writing code from scratch rather than working out of an existing code base. So basically, a few other interns and I, all of which were probably lousy at design, had to work together to create a design. Neither experience really gave enough feedback for us to know if we were really doing what was best. For all I know, I could have been learning completely lousy design practices for 6 months. My last internship, I was actually working on an old existing codebase. It finally gave me a view into what complex design looked like, though it was hard to understand why it was implemented a certain way.

Software design is massively important to a project. If a code base isn't extensible or understandable enough for example, you're going to be fighting a terrible battle to have a good product in the end. I may be asking for too much out of school. We do, after all, still have the rest of our careers to keep learning. And design isn't just some algorithm. There are good practices overall, but different situations call for different things, and that may be something best learned through experience with a specific project. Honestly, I don't know.


On a slightly unrelated tangent, I'm kind of bummed by the locking in of our schema early on. It comes off as very non-agile/XP to me. It's not letting us change design specs over time. Maybe nothing in the required specs will require a change in our schema, but for features that step out of the box, it could matter.. maybe... I do see the purpose in locking on to one so that data sharing is a lot better, maybe I've just been XP-brainwashed (or XP-empowered at least).

Test this Friday? It's going to be a fun week.

Week #6

There are a few things in computer science that belong on my "I should know more about this because I've been around this a lot and will be around it for most of my full time career". Datastores/Databases belong on that list. I've used them while still knowing surprisingly little about how they work. While I was interning over the summer at Google, I heard BigTable and other internal datastores mentioned all the time, but I never had the time to look through some information internally since it wasn't directly related to my project. Hell, I went to Big Table Cafe for lunch pretty much every day. :) Seems like I'll start learning more about this internal Google stuff from outside Google, since App Engine uses it.

Between the reading from last Friday and the reading for Monday, I've learned quite a bit about databases, and  really, I need to learn quite a bit more. Between working on the WiCS website admin panel along with Cassie, playing around on my own website, and doing this upcoming project, I will definitely learn a few things.

I'm really looking forward to the group project. The projects were really educational in CS371p and they have been so far in this class. I like the fact that the class material and the projects are distinct. We're going to be learning a lot of things not taught in class it seems, and that just makes for more knowledge, which is a great thing. I've found the projects are even more educational and exciting in this class, since much of the python taught in class is review after taking Julian Bishop's one hour python class.

Week #5

Looking back on this past week, there was nothing really memorable. It was a bit of a slow week after a test. I needed a refresher on some python stuff. I had definitely forgotten little things like the ability to loop through two lists in a list comprehension. We did get back our test scores, and I think I did better on the first test than I ever did in OOP, so I'm happy.

The project is going fine. I wish we could get it lower, but at least it's below 1.0 for now. It's actually an interesting project. Like I said last week, there just isn't enough time to make it as good as we could with more complex stuff. I was wondering if there was a time limit on the programs that were competing for the netflix prize though. I was in a really-wanting-to-program mood this past friday afternoon, but my partner wasn't available to work, so I coded some of the WiCS admin panel instead. I found a downside to pair programming. :P