Thursday Dec 14, 2006

Yet Another Blog

I've started another blog here:

http://weblogs.java.net/blog/stuart_marks/

This new blog will concentrate on open source Java issues, particularly with respect to our open sourcing efforts that are occurring in the java.net mobileandembedded community. I'll continue to post here on other topics such as agile, random technical issues, and so forth.

Friday Oct 06, 2006

It Was Twenty Years Ago Today....

Yes indeed, it was. Twenty years ago today I started work at Sun. I was just a kid fresh out of college. Sun offered me a great opportunity: to work on NeWS with James Gosling. Along the way I had a bunch of other great opportunities (some taken, some not) and here we are, in a blink of an eye, twenty years later!

I suppose it's obligatory for me to offer some then-and-now comparisons.

Obviously the company has changed a lot since 1986. It wasn't that small when I joined (probably a little over 2,000 employees) but it was growing furiously. There have been lots of ups and downs with the stock price, revenue, market share, and four rounds of layoffs since then. But we're growing again, at least a little bit.

Hardware has changed a lot too. The personal computing revolution was just underway. The PC, Mac, Commodore, Atari etc. were just toys. But "real" personal computers were engineering workstations, which was Sun's business at the time. Most of the others are gone now, but the PC and the Mac are still there. Sun still has a workstation business but it's pretty small. And of course everything is bigger and faster. It's expected for every office worker to have a laptop or a desktop PC.

Software has also changed of course. Back then we were building new window systems, which were a research area. Now there are about three: Windows, Macintosh, and X. There were also lots of operating systems. Now there are basically two: Windows and variants of Unix. (Yeah, there are quite a number of embedded OSes, but I'm talking about desktops here.) By contrast, the number of programming languages in widespread use seems to have proliferated. There have always been lots of research languages, but one now encounters many more languages on a daily basis, especially scripting languages. It's a challenge to keep up.

There has been another, quieter personal computing revolution.

The computer I use every day is a Macintosh PowerBook G4, 1.25GHz, 1GB memory, and 80GB hard disk. It's a few years, old, and somewhat pedestrian by today's standards. The computer I did most of my work on in the early days was a Sun-3/160 with a 68020 running at 16.7MHz, 4MB memory, and 71MB disk. (I started with a Sun-2 but I got upgraded pretty quickly.) Compared to then, my current computer has nearly 100x the clock speed, 250x the memory, and over 1000x the disk space. But this is all pretty obvious.

The big difference is that I own my own computer.

In fact, I own or at least control my own computing infrastructure. I have DSL, a firewall/router/wireless box, and several devices attached to my home network. This too is fairly pedestrian by today's standards, and it's not at all uncommon.

The difference is that for pretty much anything computing-related, it's affordable for me to do it myself. Back in 1986 if you wanted to do some number-crunching, store a lot of files, transfer something large from the internet, or print something with laser quality, you had to go into work to do it. Nowadays this is no longer necessary.

In fact, sometimes things are better at home. If I need a scan or a color printout, it's much easier at home. It's not that we don't have scanners or color printers at work, it's just that you have to track one down, get permission, figure out how to use it, etc. It's much easier for me to do it at home. My network isn't as fast as work's, but sometimes I get better connectivity. Sun's firewall blocks a lot of ports. Sometimes I can't things to work through the proxy. Or if I can get it to work, it kinda sucks.

So that's the biggest difference I see: the ability to control one's own computing infrastructure being affordable and commonplace.

Now, how to wrap this up? I started with a song lyric, so I guess I'll finish up with a song lyric. I can't decide on one so I'll just list a few that popped into my head, and you can choose:

  • The long and winding road... [OK, it's a cliche]
  • What a long, strange trip it's been [Sorry, another cliche]
  • Twenty-first century schizoid man [???]

Cheers!

Wednesday Sep 27, 2006

A Few Notes on Blogging

I was asked to speak to our group today about blogging and the blogosphere. Here are my notes from that talk, somewhat cleaned up and embellished, for those of you who might have missed the talk or who might want more.

I asked four questions: Why, Why, Why, and Why?

Why should you read blogs?

The whole blogosphere/Web2.0 thing is often overblown, but in a few subtle and significant ways, blogging really is a new medium. There might be 4 million blogs out there. Most of them are probably inactive (e.g. "This is my first blog entry" and nothing else) and like Theodore Sturgeon said, "90% of everything is crap" so this cuts down the numbers considerably. But this still means that there might be tens of thousands of active, interesting blogs out there.

Blogs enable you to establish a personal contact with someone you otherwise wouldn't have. People write in their own voice (usually) and this lets you get to know them a little bit. Most blogging systems have the ability to post comments, and quite often bloggers will respond to comments, so the medium is interactive as well.

At Sun, Jonathan Schwartz has taken the lead in being the first CEO to have his own blog. I believe he writes it himself, unlike most corporate communications which is ghost-written. I don't speak to him much (I met him briefly in person, once) but reading his blog gives me little bits of insight about what's going on in his head. As an employee I think it's really cool. I also believe that customers and the media find it interesting as well.

Jonathan blogs about business but lots of people blog about other topics including personal stuff. A popular blog is one by Rich Burridge who blogs about a wide variety of topics including taking his kids to the new Stanford stadium last weekend. You might or might not find what he writes to be interesting. If it's not, move on to something else; there's sure to be something interesting out there.

Why should you write a blog?

As people go about their daily business, they're constantly interacting with each other. At the water cooler, in hallways, bantering before meetings, there are little bits of insight, funny stories, jokes, war stories, news, information, updates, analysis, etc. are passed around. Usually it just bounces off the wall and disappears. Sometimes people remember it, sometimes they don't. If you think about it, this information can have a lot of value if it's written down. So, next time you find yourself telling (or listening) to one of these little tidbits, write it down and blog about it. When you share this information, others will find it valuable, they'll learn from it, and they'll learn about you as well.

Why should you blog in public?

Sun has an internal blogging system, and many people have set up blogs on it. It's readable and writable only if you're on Sun's internal network. This is OK, insofar as it's another way of improving our internal communication. But we already have so much internal communication already (email, meetings, teleconferences, webcasts, etc.) that it doesn't help all that much. It's just another way to talk to ourselves. And as my father once said, if all you do is talk to yourself, you win all the arguments.

We need to engage the outside world. The whole internet -- the blogosphere -- is several orders of magnitude larger than Sun. Inside of Sun, we're insular, even provincial. So, we need to get out there and engage the entire blogosphere, the real world, instead of being "chicken" and staying safe inside of Sun. We might get some comments we don't like, but that's how we learn and grow.

At the same time, we present ourselves as individuals. Sun isn't a monolithic, faceless corporation. It's a corporation with a lot of smart, articulate individuals, each of whom has an independent personality. This projects a much richer and more powerful image of what Sun is to the outside world.

Why should you read my blog?

You should read my blog because I post short, crisp entries on interesting and relevant topics. If you read my blog and you don't like it or aren't interested, post a comment!

Friday Sep 22, 2006

Open Source or Dirty Laundry?

As we get ready to dive into the open source world, one of the many activities that's occurring is the preparation of the code for being open sourced. There are some obvious things that need to be done. For instance, our source code includes a mixture of code that we've written and code that we've licensed from others. We'll need to separate out the latter and open source only the appropriate pieces of code.

Another preparation activity is "scrubbing" the code of proprietary information, mentions of particular customers, developers, technologies etc. This is a little less obvious, but consider the following example:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

While all of the above might be true, we probably have a relationship of some sort with Intertrode Tech and having comments like this in the code could hurt our business somehow and so it should be removed. Arguably it shouldn't have been there in the first place, but now's the time to take it out.

Another part of the "scrubbing" activity is to remove profanity and other "undesirable" words such as "hack" and "kludge" from comments. The list of undesirable words includes common tags such as FIXME, TODO, BUG, and so forth. These are usually replaced with something generic like "IMPL NOTE". This is the point at which this stops making sense to me. Comments that express strongly held opinions are quite useful and help to convey the thinking and the point of view of the author of the code. The goal of writing code in a high-level language is in fact to convey intent and semantics to other programmers. The comments are part of the code, and -- warts and all -- they help to convey the same information. Scrubbing this out can remove this information, decreasing the maintainability of the code.

Consider, for example, how much less information the above comment would contain after it has been scrubbed:

/\*
 \* IMPL NOTE - insert a time delay here because the IMPL NOTE Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be IMPL NOTEs.
 \*/

Seriously, there is a real danger of removing vital information in this process. It seems likely that the comment might actually be scrubbed down to something like this:

/\* IMPL NOTE - insert time delay \*/

which says just about nothing. It says that a time delay was introduced, but this is probably redundant since there will be something like a call to sleep() immediately below. It fails to say why the time delay was introduced, which is the most important piece of information. Without this information, the delay might remain in the code base long after it's necessary (after Intertrode had corrected its driver) because developers are too afraid to take it out. Or, they'll go ahead and take it out, leading to an all-night debugging session by a hapless developer who happens to be trying to port the system to a board with a backrev Intertrode framebuffer.

The question of profanity in code is a somewhat different matter. Personally, I don't swear very much, but sometimes a well-placed expletive is exactly what's necessary to convey the information in the right way. Removing profanity reduces the information content of the code just the same as removal of other "undesirable" words. Consider the rich texture of the comments and names in the following code, and how this texture resonates vibrantly against the vigorous nesting of the Lisp code:

GNU Emacs terminal.el

This masterpiece of coding profanity sets a standard to which we should all aspire.

Friday Sep 01, 2006

Ignore this.

(Made you look.)

Really, you can ignore this entry, I've created it for testing. There's nothing here of interest. Move along now.

Trackback test: link

Test of updating. Another test of updating...

Monday Aug 28, 2006

Open Source Means Open Communities

The use of the word "source" in the term "open source" originates from "source code" meaning programs, programmers, hacking, arcana, great hacks, kludges, staying late at the computer center, lots of caffeine, long hair and scraggly beards, Szechuan Chinese food, and so forth. As Annette pointed out in her blog entry Open Source Means Closed Communities, this emphasis on programmers and programming tends to shut out contributions from anyone other than programmers.

But let's be clear: this image is not of a typical open source project, but of a stereotypical open source project. The values of a community reflect the values of the members and of the people who created it. Just because a project is now "open source" doesn't mean that hackers are going to swarm in and push out everybody else.

Now, Annette will claim that software projects have always had a cultural bias favoring programmers over other contributors. I'll be one of the first to agree. However, open source projects don't threaten to restore this bias. Indeed, open source represents an opportunity to create a new community with a new value system, ridding us of this bias once and for all. This is the way to meet Annette's challenge.

Finally, Annette closed her entry with the question, "Does that mean that a QA engineer might just have more influence than a programmer one day?" That deserves a reply, but in another blog entry.

Thursday Aug 17, 2006

A Longtime Java ME Guy

This entry is a response to an entry on Anet's blog, Time to come out of the closet.

Not as long as Anet, but perhaps almost as long. I got involved with Java ME (really, the precursor to Java ME) about seven years ago, back when KVM was the next big thing and MIDP hadn't even been started yet. I did some work with NTT DoCoMo, I was on the MIDP 1.0 and 2.0 expert groups, and I've done a lot of work on Sun's products in this area.

Now plans have been announced to open-source Java ME. Time to strap in and hit the throttle!

Tests have a better memory than you do

My past several blog entries have been about testing, more precisely about unit testing or test-driven development. I suppose I should talk about how I got started on all of this.

Up until few years ago, I developed code in a "conventional" style, that is, without unit tests. I kept hearing about unit testing and test-driven development but I didn't know what to make of it. I read a couple articles and it seemed sorta weird, but I didn't really catch on. But, as my experience shows, you can't catch on to something just by reading about it. You have to do something and experience it.

So, I decided that when I next had a couple spare hours free (naturally, this was a major source of delay) I assigned myself a simple programming task. The actual task isn't relevant, but it was simple enough that I could implement something of interesting complexity within a few minutes and then add features incrementally.

But I did eventually get the time to do this. I downloaded JUnit from junit.org and followed the procedure of writing the test for the code before writing the actual code. I felt really stupid at first. I couldn't even compile the test, since I hadn't written any code yet, not even a stub! But I kept going: I added the code, and then the test passed. I added another test (which failed, of course) and then I added the code to make the test pass. And so forth. I even started taking shortcuts by writing the test and the code at the same time. It's not strictly by the book, but what-the-heck. After a while, I had a couple hundred lines of code and a dozen or so unit tests. Things were going pretty smoothly.

But then something really interesting happened. I had implemented features A, B, C, and D and their corresponding unit tests. I added a test for feature E and then code to implement feature E. I ran the tests, and the test for the new feature E passed. But the test for feature B failed!

This came as quite a surprise to me. After programming for only a couple hours, and with only a couple hundred lines of code, my unit tests knew more about my code than I did. When I implemented feature E, I thought it would work -- and it did -- but I also thought that it wouldn't break anything else. I was wrong. It just goes to show that your unit tests have a better memory than you do.

I've been test infected ever since.

Wednesday May 03, 2006

Tests Embody the Results of Thinking

I was talking to one of the engineers on my team the other day about bugfixing and unit tests.

We've reached the bugfixing stage in our project. To fix a bug, one must do a lot of thinking about the case that fails. Clearly, one must change the behavior in a particular case from incorrect to correct. But one must also ensure that the correct behaviors that occur in all the other cases are preserved. So, the goal isn't just to make some test change from fail to pass; it's to make sure that all the cases are handled correctly at the same time.

It's surprising how often people forget this. Sometimes a developer will make a change, and if the failing test succeeds, they think they're done. If they haven't ensured that all of the other cases are still correct, they're being irresponsible. (A greater irresponsibility is with managers who don't understand this.)

When dealing with code -- whether writing it initially or fixing bugs in it later -- a developer has to do a tremendous amount of reasoning, analysis, and thinking about all the cases the code has to handle. Unfortunately, the results of this thinking are rarely written down anywhere.

Sometimes these results are written into design documents. These are usually separate from the code, they get out of date, and nobody reads them anyway. Sometimes these results are written into comments. People sometimes reads the comments, but they're so often out of date that they aren't to be believed anyway.

“When the comments and the code differ, both are probably wrong.” -- attributed to Dennis Ritchie

The best place to write down these results is in unit tests. A good suite of unit tests acts as a reviewer who checks all the "other" cases for you automatically. If you run the unit tests all the time, they don't get out of date, either.

Next time you're reading a piece of code and you gain a significant understanding of it, don't throw away that understanding. Write it down in the form of a unit test.

Thursday Apr 20, 2006

about smarks

My name is Stuart Marks, and I've been a software engineer at Sun since 1986. I'm currently working on our Java ME products.

I don't know anything about professional wrestling.

Wednesday Apr 19, 2006

Insights from Bob Martin's Agile Toolkit Podcast

Thanks to David Carlton for posting a link to the first Agile toolkit podcast in one of his comments.

In this podcast, Bob Martin restated some of the critical XP practices, from which the other practices will tend to follow. I thought this was OK but not particularly enlightening. I did find some interesting insights in some other comments that Martin threw in offhandedly.

First, there's the statement that the purpose of testing is to determine when we're done, not to find bugs. This probably isn't original, but it's an important point. I constantly run across people who think that the purpose of testing is to find bugs.

Second, there's the notion that there is a QA group whose jobs is to be specifiers for acceptance tests, instead of executing tests on the finished product. I hadn't heard this before. This seems to work well if you're using something like FIT for acceptance tests. I'm not sure how one would apply this to platform software products (which is what I work on). Something to think about.

Finally, there was the idea that QA can get ahead of developers in mature organizations, getting the tests ready in advance of the product being ready. This is TDD in the large, and it makes sense. Unfortunately I've never seen this in practice. It sounds like something worthwhile to strive for, however.

Saturday Apr 15, 2006

Increase the Ratio of Thought to Lines of Code

More on pair programming...

Nearly two years ago, Rich Berlin blogged some observations about pair programming. He mentioned an idea that he and I came up with: Increase the ratio of thought to lines of code.

Turns out that a similar piece of paper from that meeting I had with Rich is still posted outside my office. I think the meeting was all the way back in 2001. It wasn't actually that much of a meeting, as I recall, it was more of a whiteboard conversation. But it did result in a few insights that I thought were worth writing down.

One topic in particular is the number of bugs programmers write. Dijkstra observed that “If debugging is the process of removing bugs, then programming must be the process of putting them in.” My observation is that programmers do write lots of bugs, most of which are easily preventable. <lament>If only programmers were more careful!</lament>

This is really a counsel of perfection. Simply telling programmers to be more careful or to write fewer bugs is ineffective. One way to let programmers be more careful is to take some pressure off and not overload them. Programmers under pressure often subconsciously or willfully ignore potential issues, since they are apparently obstacles to completing the task at hand. With less pressure, programmers can take more time to think about their code and to investigate unresolved issues instead of just checking it in and moving to the next task.

But that doesn't mean they will take more time to think about their code. That's where pair programming comes in.

One aspect of pairing is keeping each other honest. A senior engineer paired with a junior engineer can instill greater discipline in the junior engineer, encouraging him or her to fix the problems now instead of postponing them until later. It works the other way, too. As a senior engineer, if I know a junior engineer is watching me, I feel compelled to set a good example. I'm always on my best behavior. (And boy, is that tiring.)

Another aspect of pairing is, as Rich said, “Two heads are better than one.” Two people will be looking at different things. The union of problems they'll find is greater than either one of them alone. This applies for senior-junior pairing or pairing between peers. Nobody is so perfect that they never make mistakes.

There are a few other topics from that discussion with Rich that I'll save for future blog entries. Stay tuned.

Friday Apr 14, 2006

Let's Look at the Code

Like many programmers, when I first heard of pair programming (one of the eXtreme Programming practices) I thought “Ewwww!”

Pair programming can be difficult and tiring. We don't do XP in my project and we're not likely to start soon. However, pair programming can be extremely effective in certain cases, such as for teaching and mentoring, for diagnosing obscure and difficult bugs, or working through really hairy code.

But how can you get people to start pair programming if they don't want to? You pretty much can't dictate “henceforth, everyone must start pair programming.” Well, you can dictate, but people won't follow. Or if they follow, they'll do so in a reluctant, grumbling fashion. Not the best way to improve productivity.

Yet I do find pair programming valuable in many circumstances, and people often don't pair program even when it's useful to do so. How to start?

I'm a senior engineer, and engineers on the team often drop by my office to ask questions about how to solve some problem they're working on. It's part of my job. I used to answer questions by drawing on the whiteboard or by waving my hands and describing how I thought a solution would look. More recently, however, I'll say something like “Hmm, well, let's go look at the code.”

I'll then wander over to the engineer's office and ask them to show me what's going on in the code. They'll pull up source files and start showing them to me in an editor. Pretty soon we'll run across some code that's not behaving quite right. We'll talk a little bit about how the code should be behave, and what changes need to be made to fix it, and so forth. I'll say, “Well, why don't you check out the file and we'll make those changes right now?” And we do. And pretty soon, we're pair programming.

Some time ago we had started advocating pair programming in my team, but nobody was really doing it. At one point I used this technique on one of the engineers. At the end our the session, I asked her, “Did you realize we've just been pair programming for the last hour?” The grin on her face was priceless.

So maybe we should pair program but not say we're pair programming. Just say, “Let's look at the code.”

About

user12610707

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today