Blast from the past
Indeed, it is a blast from the past; my past. One of the first logbooks I had to write was for a course called “Software Architecture and Component-based Design”. It was the fateful online course that required the Evans book, and it coincided with the formative Project, which was the genesis of this blog.
I have included excerpts from three of my logbook entries. Join me in a walk through time to 2007. A simpler time. Come and let us scoff at my year-old thoughts.
This first entry was about eXtreme Programming.
7/2/2007
There were a pair of interesting quotes in the lecture this week:
“Develop together – both at the screen, mouse and keyboard concerned with implementation, other more globally”
“XP matches observations of programmers in the wild”
I’m not sure about the general case, because I can only speak for myself: to me, yes, programmers in the wild like to be close to the code so they can run applications in small chunks and get immediate feedback; on the other hand, programmers in the wild are not well-suited to having one of their peers peering (hah) over their shoulder inspecting their code as they write it. Generally, especially when learning a new API or a new protocol, I need to write experimental and generally messy code in order to get a concrete idea of what I am doing.
While most programmers are probably introverts, like myself, this is like taking bad-tasting cough medicine. Constant or consistent inspection of your code is the best thing for you.
The part about writing messy code is still true for me. I don’t even try to write beautiful and elegant code right off the bat. I write little ugly chunks, get them working, and then refactor them. Rinse and repeat. I am the first to admit that I am not a l33t guru.
And another thing: when I’m dealing with either a conceptually difficult algorithm or a segment of code that clearly should work but is inexplicably misbehaving, I’d imagine that having to explain to my buddy sitting next to me, who is probably bored because he’s not in the driver’s seat, what I’m doing and why I’m doing it would only distract me from the required deep thought.
This hasn’t changed. When I’m in deep thought, I’m in deep thought, and I can’t be distracted by having a conversation about it. I need to have original thoughts to talk about first, right?
There is also the issue of self-consciousness — do I really want a fellow programmer, who is probably better at this craft than I am, witnessing my inevitable infinite loops, syntax errors, and de-references of null pointers?
Oh, sad but true. I still make these mistakes, though with less frequency than I used to. The complaint still applies. If people sat down and actually watched me code, they might question my skills. I do get the job done, but it isn’t pretty.
(my brain, not on drugs, but on code)
I’ve been accused of arrogance because of being a Man Of Few Words. Have they ever thought that the exact opposite is true — that I’m excessively modest because I know there are many people out there with the raw talent that I have to learn?
Coding has always been a private experience for me. Often times, I will be doing something completely away from a computer screen; for example, taking a shower. And then, it will hit me. Ghostly, disturbing images of fragments of data being manipulated by the algorithm I should’ve written while I was behind the keyboard. And I’m not sure how well I would be able to verbalize these sorts of images to another person until they are written out in code.
Heheheh, visions.
Then again, I can readily blame the educational system at this poor excuse of a college for indoctrinating us into a private coding mentality, and when we are presented with the opportunity to work with others on programming assignments, nobody really wants to because we’ve all developed or own bad habits and specialized areas of incompetency, and I don’t want my grade to rest on something I can’t control. Just a thought.
Oooh, characteristically scathing hatred for my university. I remember those days. While I still hold generally the same opinion today, I’m a much happier person today than I was when I wrote that. The primary reason for that change is because I’m not in school anymore. At 7:29 PM on a Saturday night a year ago, I was doing some God-awful assignment, cussing at my laptop, and punching my keyboard. Now, I’m writing a blog post and getting ready for a night of drinking under the red lights while painting the walls of the UAC base with demon blood.
The criticism of computer science education is as relevant now as it was then. Team programming needs to be more than a senior project or something you get a glancing introduction to during your co-ops.
(any boss who puts this up in the halls of the office has my sincere respect)
The next entry was all about what the hell software architecture is anyway.
7/5/2007
I am including a correspondence between the instructor and I for safe-keeping:
Forgetting my Bernsteinian roots on this subject, this excerpt is from http://www.sei.cmu.edu/architecture/essays.html#difference
“Processes and similar elements can also be non-architectural. Suppose that the architect gave you a budget and the freedom to create up to 12 tasks and that these tasks do not synchronize or interact with any other tasks outside your work assignment. In that case, we could make the same argument: that these tasks, or elements, are non-architectural.”
Similar elements to processes would be, I infer, threads. Now, once upon a time, I planned a system that was going to have a VB.NET front end (UI) that would gather some data from 500 servers on our network, and dump the results in an Access DB. So I had something of an architecture.
When I implemented this system, the grabbing of data from 500 servers took a while because they were spread throughout the northeast. So, brilliant bulb that I am, I said I’d run this in its own thread.
I remember that project vividly. To be specific, I was using BeginInvoke and EndInvoke. This entry was the genesis of the “My Definition of Software Architecture” post.
Now according to the quote above and the article from which it comes, this is not part of the architecture because the architect didn’t specify it and the threads aren’t available to other modules. On other other hand, in this course we have studied software connectors as part of architecture, and one of the connectors was the arbitrator. Since this is a software architecture course, this leads me to believe that this is part of architecture.
So in the project I used as an example, would that thread be part of the architecture or not?
That is the $64,000 question, isn’t it, my year-and-one-month-ago self?
(Wow, just wow)
Thinking back to this project, I would have to say that the decision to use threads was…architectural, primarily because I made the decision, not because I was a brilliant bulb, but because requirements forced me to create a responsive and informative user interface.
The target user of this little tool was a not-so-brilliant bulb when it came to computers. If you didn’t tell her exactly what to do and how to do it, it wouldn’t get done. If you even moved an icon on the desktop to a different location, you risked her not finding the icon and subsequently not doing whatever simple task you had delegated to her.
I can also add that the decision was architectural using Intension/Locality. The statement: for each server scanning task, there exists a thread such that the thread fulfills the task. The entities are tasks and threads. Proof: add a task. The statement doesn’t hold.
Finally, although the argument is tenuous, I can say that using threads for each task was architectural because, after all, I would need to code in a language and on a platform that supported threads. Nowadays, this is like saying you needed to write the code with a keyboard and not punch cards, but I technically, the argument is still valid.
By the way, I recommend the software connector paper by Mehta, Medvidovic, and Phadke. Their poster of taxonomy is cube-worthy.
From the instructor: “Ahhhh now you see the confusion of not having a strict definition of architecture (and I suspect there never will be one). If the architect decides either on her own or because a stakeholder emphasized it that X is important to nail down then it is part of the architecture. This reflects the inward/outward designer/architect description. If it is deemed vital to the success of the system then often the architect includes it. So a long preface to my answer of yes it is part of the architecture. ”
And Professor Vesonder was satisfied with the requirements argument.
The last entry we’ll look at was about a design pattern.
7/10/2007
I don’t think I have had to work on a project that was complex enough and had enough responsibility at the same time to seriously look into using design patterns in my design.
Of all of the design patterns in the lecture, one of the most interesting to me was the Bridge pattern. Separating implementation and interface so they can vary independently seems very powerful, though that phrase seems to be something of a misnomer. When I first read it, I thought it means that I could vary the interface of a class and the implementation of that class independently, which didn’t seem right to me. How could I vary the two independently if there are dependencies on method and variable names of a class?
Then upon reading a clarifying concrete example (http://en.wikipedia.org/wiki/Bridge_pattern), I see now that the Bridge pattern might be much ado about nothing. All it really looks like is we have class A that needs to make use of interface B, so we declare a member of interface B in class A. Then there are classes B1, B2, …, Bn that all implement interface B, and as a result, class A can have up to n different implementors of interface B. This seems like well-structured OO to me. I guess I’m missing the magic of this pattern.
I gotta tell you, looking at the Bridge Pattern again, I initially agreed with what I wrote here. But it then hit me that “implementation” and “interface” here are not the technical terms of the implementation of a class and the interface of a class.
This pattern uses those terms as domain terms; part of your domain is classified as “implementation” — your drawing API, the road for your car, the bulb for a lamp. The interface is the object using the implementation: shapes, cars, lamp. In this way, I suppose the description of the Bridge pattern is correct.
However, I do consider this to merely be solid OO design. Describing it in such a sensational manner, without even qualifying what you mean by “implementation” and “interface”, is still puzzling.
Thanks for joining me on this journey to the past. Please watch your step off when climbing off of the teleportation pad, as some parts of your shoes might have disintegrated during our trip through the wormhole.
