Posted by Skrud at Tuesday, October 23rd 2007 at 9:05am
Being at OOPSLA is like seeing a live show of all the blogs that I read. The discussions are profound, and they’re everywhere, at every turn. The attendees at ooPSLA all seem passionate, smart and opinionated. I’m learning incredible amounts just being around it all!
Anecdote from Rebecca Wirfs-Brock: “What’s the difference between an extroverted software developer and an introverted software developer? The extroverted one stares at your feet when talking to you.”
Quote from Don Roberts: “Teaching C++ to freshmen makes me feel like a child molester.”
Here’s the fancy jersey that all student volunteers get to wear this year. I love the colours!
Apparently, attendees often try to buy Student Volunteer shirts at the conference — or afterwards on eBay. I’m not sure I want to sell mine. I think it’ll be an awesome souvenir.
Tags: 2007, design, oopsla, soen, software | no comments
Posted by Skrud at Tuesday, October 23rd 2007 at 1:26am
Early Sunday morning at ooPSLA I had the pleasure of participating in DesignFest ‘07. The concept is simple: Get people to try attacking the same problem but in different ways, and have them compare notes at the end. We were a pretty small collection of people, ranging from programmers working in various industries (military, medicine, academia), to consultants, professors, and students.
The problem we were given came from Don Roberts, whose wife is a veterinarian. We were tasked with coming up with a design that would allow a veterinary hospital to keep track of its patients and their owners and bill them appropriately. Sounds simple, until you realize that you can have race horses owned by multiple people, each with a different percentage stake… and, of course, many more complications. The group quickly divided into two. One group wanted to try a pure Test-Driven Development (TDD) approach, while others wanted to go for a Prototype. I was in the prototype camp.
The interesting thing about a prototype, is that while the actual development is quick (in theory), there’s still a good deal of work that needs to go into the design before you can start programming. A prototype is usually a set of minimal functional requirements that sort of work. In that sense, it’s not too different from “hacking”. (Yes, we got into a discussion about “prototyping vs. hacking” that derailed us for a few minutes). What happened was we ended up focusing all of our energy (and time) on coming up with a solid, complete Object-Oriented design for our solution. The result of our design was little more than a class diagram on paper, but we were able to work through every use case thrown at us.
The TDD team found that they, too, needed some initial design work to be done before they could start writing the test cases that would yield code. I have trouble wrapping my head around a pure TDD approach. I understand how TDD can work if your requirements are well-defined and you already have a design that you can code tests against. The idea is that you write test cases for the design before you write the actual code. They will fail initially, and your goal as a programmer is to make them pass. In that sense, it is indeed Test-Driven Development. I’m not sure the concept can be extended to Test-Driven Design. The TDD team had little more than one test case, but they had actual code for one of the use cases, which is more than what we had.
The ensuing discussion was extremely stimulating. It’s amazing what happens when you get a bunch of really smart software geeks in a room together.
The key realization that I took away from this experience was that software design is a social activity. Even though we hadn’t met each other previously, our team had to work together. We had to help each other out and make sure we were all on the same page. We had to communicate. It was amazing that we didn’t have a lot of trouble doing it, though. We mostly seemed to agree and moved along at very reasonable pace. Maybe it’s just because we’ve all trained our brains on OOP for so long.
One question in the discussion stuck in my head the most, and I’m still thinking about it. Don asked “What is the language of design?”. Since software is collaborative and social, it follows that like any human language, we must take some concept from our minds and communicate it to someone else. If any non-programmer happened to be walking by our table, we would have sounded like the Children of Tamar. Our speech consisted of terms taken from object-oriented programming (”object”, “class”, “instance”), UML (”association”, “composition”, “aggregation”), and Design Patterns (”state pattern”, “template method”, “strategy”). And that was just the spoken part.
Software Design has a grammar. There is a way of communicating design that involves a vocabulary as well as a set of rules describing how to put sentences together. And I don’t mean English. Design is more like a mash-up that derives itself from UML and Design Patterns and English. Whatever it is, we need to ensure that those designs we have floating around in our heads can remain intact after we’ve thrown them into the ether. I think this is where a formal design language specification like UML falls short. It’s so restrictive that most UML tools require you to input far too much information before they’ll display a simple diagram. Thus defeating the purpose. UML diagrams need to be free-flowing and erasable. The language doesn’t have to be perfect, it has to be understood. More importantly, it doesn’t have to be understood by a computer — that’s what programmers are for. But programmers are people. So, design has to be understood by people. People are capable of parsing an imperfect sentence that might not be “grammatical” according to a formal specification, but can still be understood by those natural language processing mechanisms we call brains. It all comes back to software design being a social activity.
Tags: 2007, design, events, language, linguistics, oopsla, soen, software | 4 comments
Posted by Skrud at Tuesday, June 20th 2006 at 7:59pm
Working is great. It’s great for my learning, it’s great for experience, it’s great for making money, and it’s great for my ego confidence. It’s not all great though, just mostly great.
What I Like About My Job
- I get to make decisions, sometimes big decisions. My input and ideas actually get put into practice. I’m not just sitting around taking orders, I’m actually doing stuff.
- I’m learning a lot. I’m learning a ridiculous amount. Reading about Design Patterns is one thing – you can’t really appreciate them until you see them in action… and by that I mean I often end up doing something based purely on the principles of “good design” and, whether I was conscious of it or not, it turns out I had applied some pattern or other. Now I’ve learned how to recognize the patterns when they appear, and figure out in advance when to apply them. It’s almost subconscious.
- A really informal working environment. Everybody in the office is extremely friendly and down to earth, and more than willing to help you find stuff out if you’re stuck or lend a hand if you need it. The managers are readily approachable, too. I’m still trying to find the right balance of laid backed vs. hard working that matches the environment though – sometimes I’m worried that I’m not being social enough, but if I do start getting social then I worry that it might look like I’m slacking off too much… I digress. Informal working environment == cool.
- Applying everything I’ve learned at school. I had to develop an architecture and come up with an Architecture Document describing it. I also got to code up a small prototype, Unit testing all the way. I use Eclipse’s refactoring tool a lot, and it saves me hours.
- I have my own cubicle and my own extension!
What I Don’t Like About My Job
Most of the things I don’t like about my job have to do with Corporate Policy, which no one can really do anything about… Still, they’re pretty irritating.
- I can’t check my e-mail at work. That’s right, Gmail is blocked by the proxy due to “export restrictions” under the corporate security policy. It might not seem like much, but not knowing what’s in my inbox is a maddening experience. Gmail is practically my only contact to the rest of the world.
- I can’t bring my laptop in to work. And I don’t mean “I can’t use my laptop at work.” I mean, I can’t bring my laptop in to work, even to let it sit in a backpack under my desk all day. Because it’s not an “approved computer hardware device” or something like that. It’s capable of copying data, sending transmissions, and whatever other security liabilities which potentially involve having a foreign laptop in the building. The days I do need my laptop after work, I actually have to leave it with the security officer all day – which sucks because she leaves an hour before me.
- People don’t call me Skrud. I’m not used to being referred to by my real name.
- Until I get security clearance, I’m only allowed in the building in between 7:30am and 5:00pm. Which sucks because that is exactly how much time I need to spend at work most days. Luckily they don’t care if I stay a little later to make up for coming in late or something, but if I happen to go to the bathroom after 5:00pm sharp, I get locked out of the office and have to wait for someone to let me back in.
- Lunch is only 30 minutes.
So far this experience has been excellent overall. I still have some 6 months to go, and I think I’m going to enjoy them. I don’t know if I’d consider Lockheed for a career, but I wouldn’t rule it out, either. My current dream job is at Google, but dreams fluctuate.
Tags: life, school, software, work | 11 comments
Posted by Skrud at Wednesday, May 24th 2006 at 7:12pm
Okay, so I don’t really make things that go boom, I make command and control systems for things that boom… Well.. I don’t really do that, either. I’m a software engineering co-op, and I write documentation (…for command and control systems for boats that launch things that go boom). Actually I’m working on a prototype framework, but I’m not entirely sure how much I’m allowed to disclose, so I’ll leave it at that. (Yes, saying things like that gives my already-inflated ego an unnecessary boost).
I managed to nail an internship at Lockheed Martin Canada for the next seven months. I’m not in a co-op program, so that really means that I’m raping my course sequence in exchange for actual work experience. Lockheed didn’t care that I’m not a co-op student and gave me the job anyway, and I’m glad they did. I had my first day of work yesterday, when I read so many training manuals that I went cross-eyed. Today, though, I started to get involved in real work. And what is real work? Why, it’s the same stuff they’ve been teaching me in school. (Please feel free to experience shock).
Tomorrow I’ve got to get started writing … a Software Architecture Document. If you would’ve asked me about SADs a couple of months ago, I may have snarled and clubbed you over the head (or, more likely, cowered in fear). But now I actually look forward to it. I’m itching for the opportunity to show off what I’ve learned, and apply it.
I get to be elbow-deep in the design process. Not only am I supposed to write up the architecture document, but in so doing I’m to analyse and attempt to find flaws in the design. I’m encouraged to offer my input and potential improvements, to be critical and to discuss alternative solutions. I don’t feel like a worthless intern grunt; I feel like a team member. More than that, I feel validated in the fact that the stuff I’ve been doing in the classroom is being directly applied to the work I’m doing in industry. I feel well-prepared and it feels great.
The prototype I’m working on is being coded in Java, and I believe it’s actually the right tool for this job. (If you weren’t shocked before, you probably are now. When have I ever said anything positive about Java?). We’re writing a framework, and Java’s Foundation Classes provide an excellent foundation to build on. My boss loaned me a book on Swing, and it’s not bad at all (I really like the Layout classes). I’ve been learning a ton, and I’m looking foward to the next seven months with increasing enthusiasm.
Tags: documentation, programming, school, soen, software, work | 9 comments
Posted by Skrud at Tuesday, May 2nd 2006 at 5:20pm
Bad writing is a pet peeve of mine, particularly if it’s excessively prevalent in something I have to read. I’m not talking about improper grammar or spelling mistakes – those annoy me, too, but to a lesser extent. I’m talking about bad writing.
A lot of technical documents are badly written. This has nothing to do with the technical competence of their authors, but a lack of elegance with the English language. Some of the greatest minds in Software Engineering aren’t some of the greatest writers, which is no great surprise. Yet still they have to publish papers about their research, and then I have to read them while studying for my exams.
I know I’m not the only one who feels this way. Joel Spolsky has even gone so far as to compile a book: The Best Software Writing I which is a collection of well-written articles about software. To quote his blog:
The software development world desperately needs better writing. If I have to read another 2000 page book about some class library written by 16 separate people in broken ESL, I’m going to flip out. If I see another hardback book about object oriented models written with dense faux-academic pretentiousness, I’m not going to shelve it any more in the Fog Creek library: it’s going right in the recycle bin. If I have to read another spirited attack on Microsoft’s buggy code by an enthusiastic nine year old Trekkie on Slashdot, I might just poke my eyes out with a sharpened pencil. Stop it, stop it, stop it!
I think there are two scales that you can analyze a particular technical document on (and this may extend to other kinds of documents, but I don’t know about those): How easy is it to read? And how easily can you extract information from it? There were about four things I had to read in studying for my Software Architecture course, and they each fall into different places in the spectrum. However, I don’t think an article can be easy to extract information from if it isn’t easy to read first.
Formal Language
Formal language is silly. In formal language the writer attempts to avoid any identifying remarks. The writer completely removes himself emotionally from the document. The writer does not use contractions and writes in the third person. When one is writing in formal language, one does not infer gender on any third-person singular pronoun. Instead, one must awkwardly use the gender-neutral “one” and refer to themselves, if they must, as “the writer”.
Here’s the thing about formal language: your brain doesn’t care. It’s much more difficult to retain knowledge from something written formally as oppose to conversationally. Formal language reads as if it were written for robots, not for humans. I suppose there is an assumption that when you’re writing a technical document, that your target audience includes technical people. All too often authors focus on the technical but forget the people. Regardless of the education level of your target audience, no matter who they are, they are people. Whenever you’re writing something, I think it’s fair to assume that it’s going to be read by a person, and not by a machine. So why not write something that you think a person would be able to read?
Kathy Sierra has tons of stuff promoting the use of conversational language over formal language. Here’s a tidbit from Creating Passionate Users:
When you lecture or write using conversational language, your user’s brain thinks it’s in a REAL conversation!
In other words, if you use conversational language, the listener/reader’s brain still thinks it has to hold up its end, so it pays more attention. It really is that simple, and that powerful (at least if you really want to help users pay attention and remember your message).
I for one believe that it’s much more important to get your message across clearly than it is to sound like a pompous, professional ass. There’s no point in writing something that no one is going to understand. In fact, I suspect that an overuse of formal language may be trying to cover up a lack of understanding on the author’s part. Since it’s much more difficult to parse “formal” documents, it’s tougher to pinpoint inaccuracies in the arguments.
Philippe Kruchten’s paper on the 4+1 View Model of Architecture is a great example of a paper that uses formal language way too much. The phrase structure is awkward at best, and I had to read each tedious paragraph repeatedly to get anything out of it. The paper was, however, chock full of useful information.
Counterpoint
Conversational language can be a great help in terms of being easy to read. Unfortunately, that’s not the only thing needed in a technical document. Ultimately, the document exists to disseminate information, not to entertain you. That’s no excuse to write tediously and formally, but it is an excuse to pay attention to how well your writing presents information.
We had to read Patterns of Enterprise Application Architecture by Martin Fowler. I think this book is a great example of something that’s very easy to read, yet at the same time is difficult to extract information from. Fowler writes very well. He writes conversationally, as if he’s talking to you and telling you about common problems in Enterprise software architecture over a pint of Guiness. The problem is that I didn’t find the book to be very well structured. It would be very easy to read, but there also seemed to be a lot that was simply glossed over. In one sentence, Fowler may make an abstract reference to something incredibly important and then never return to that topic again. He might say something like “if you use a Data Mapper then Lazy Initalization is not enough, and you must use a Proxy” – but he never says why. (It took me until literally the day before the exam to understand this, when really he could have summed it up in a sentence or two).
Conclusions
It’s very difficult to find a balance between clear, concise writing and detailed technical writing. One the one hand, you sound like an android – or worse, pretentious. On the other, you can easily let valuable information slip through the cracks in your writing, and your technical document becomes no more useful than celebrity gossip. You need to experiment in order to try and find the right level of abstraction for your writing. It’s not at all different from experimenting to find the right level of abstraction in your object-oriented software. With time, (I hope) it’ll become second nature.
Editing can go a long way. I think technical papers should get reviewed not only by other technical people, but also by writers. Someone who isn’t necessarily familiar with the technical field surrounding the paper’s context, but is a language expert capable of pointing out awkward written constructs and making the paper readable by humans. I for one would love to read software architecture documents as naturally as my RSS feeds.
Caveat Emptor
I’m in no way an “expert writer”. I have little experience in my academic career reading technical documents, and I have minimal experience writing. All I know is what kind of writing I find helps further _my_ understanding. These are only my opinions, so take everything I say with a grain of salt.
Tags: rants, software, writing | 5 comments
