Burping Software and Babies

Reflections on parallels between parenting and software development

Burping Software and Babies …

I’ve been non-existent in the blogging community for awhile now, consumed by taking care of my second baby, now nearly 4 months old. But as I was sitting up with him the other night, it occurred to me that burps in babies are kind of like bugs in software. So that’s how I’m gonna connect my first blog in a long time with this very consuming activity called parenthood.

Babies need to burp after eating, most of the time. So we sit them up and burp them over and over again, for countless minutes. Sometimes I’m more persistent, bouncing him up and down a bit while burping, even tackling a couple of flights of stairs to break that burp free. Sometimes the burp finds me … sometimes it escapes me. Sometimes, there’s no burp there at all. But how do I know?

Usually, at some point, I declare the baby burp-free and put him back to bed … ah, but only to find that he’s up and screaming an hour later with a burp that I “missed” and if I’m particularly unlucky, he’s barfed all over himself and now I have to change him. This ensures that I’m totally awake and so is he. NOT good, especially in the middle of the night.

Sounds kinda like software, doesn’t it? We build code. We write tests to look for bugs. We jostle our code around, akin to bouncing the baby, looking for bugs. We’re SURE there are bugs there and continually “burp” the code. But at some point, we declare the code “burp-free” (at least for now), and go on to the next thing on the list. And when we’re particularly unlucky, it barfs all over us later. And “middle of the night” for babies equates to “just before release” in software development. Sigh.

Of course, I don’t have a solution other than using all of the tools that nature and technology have given us to get those darned burps (uh, bugs) out of our code. I don’t have a solution to figure out when the baby is done burping either. All I have to say is that after a few more months, the baby will be able to burp on his own. Unfortunately, even a nice suite of automated tests won’t achieve that independence.

Yeah, yeah, I’ll shoot for a more technical blog next time. Hopefully you were a tiny bit entertained by this one.

Dianne

Consulting for the Risk Averse?

Getting from there to here
Given my risk averse nature, most people find it amazing that I live my life as a freelance consultant.  I guess, when I sit back and think about it, I do too.  I was thinking about this in detail as I prepared to give a talk for a class at the University of Michigan, to a group of computer science students.

When I finished college (in 1986), I took a job with a medium sized company and worked there for a year or so.  I wanted to be closer to my family and friends, so I found a new job in the metro Detroit area, and moved back.  This job was with a small company but it had a larger, successful sister company.  I left the company when I found out that it was using the sister company to make payroll and was struggling in a time when the rest of the industry was going gangbusters.  Did I mention that I was risk averse?

In any case, I worked for a few years for a larger company, ultimately bought by a huge German company.  I liked my job, but I was trying to go to graduate school at the same time and found that working during the day and taking classes as night was very difficult for me.  I decided to pursue my graduate degree part-time.  This risk averse person quit her job and went back to grad school for two years!  Perhaps that was the first part of the transformation?

Why I’m the Company Curmudgeon

Why does SRT have 2 resident Microsoft experts and a non-Microsoft holdout?

SRT Solutions consists of 3 partners: Bill Wagner, Josh Holmes, and myself. Together, we mentor developers, working with them on projects so that they become self-sufficient in new technologies. Bill and Josh are particularly adept at Microsoft technologies, while I have made a name for myself embracing the “other” camp: Java, Unix, you name it. While we are all quite capable in both arenas, we clearly have our own pet languages, utilities, and programming environments.

Bill and Josh anxiously await the MSDN updates and install the latest and greatest betas of tools, languages, etc. I seek out alternate utilities, like Mozilla’s Firefox (web browser) and Thunderbird (email reader). I rarely use the DOS prompt, preferring instead the MKS Korn Shell and the Unix utilities that ship with MKS. I’ve been known to freak out my business partners a bit by editing something quickly in “vi” instead of notepad or another Microsoft utility.

I’ll be the first to admit that Microsoft has wonderful tools. They have the insight and the resources to put together a group of tools, especially for programming, that work great and make coming up to speed with their product very easy. This relieves their developers of having to choose a development environment. The Unix/Linux world does NOT have the same mentality. Instead, “you can use anything” is seen as an advantage. In truth, it may yet lead to the downfall of the “other” side. Programmers scramble to find tools to use together, and team discussions about “standardizing on tools” often turn ugly. Microsoft programmers who might be doing a simple project in Java, for example, are turned off by the whole thing and often never write another Java program. On the other hand, I have also been stuck using Microsoft tools, where the tools do some “black magic”, generate code, and it’s hard to know what they did or to undo it. This is not as much of a problem in the “do it yourself” camp.

So, are those small incidents why I persist in my quest for good Unix/Linux/Java tools rather than “joining the Dark Side”? Not really. The truth of the matter is that our clients are diverse. Sometimes a Java solution is what they want, either because of legacy issues, or because their application has a particular need that warrants something other than a Microsoft solution. In striking a balance between Microsoft technologies and non-Microsoft technologies, SRT Solutions can choose the right programming language for the client based on business needs rather than shoe-horning every problem into a Microsoft-based solution.

Also, it’s good for someone to remain Unix/Linux-literate, since we do have clients that are multiplatform. And if you look deeper, you will notice that at the core of every decision that we make in staying on top of technologies, Bill, Josh, and I are more alike than different.

Of course, it IS fun to tweak Josh and Bill every once in a while.

Swing layout managers

Use a GriddedPanel to simplify Swing programming

Anyone who has ever done any Swing programming has had to manipulate layout managers.  Sure, you can use the FlowLayout, but then your controls get placed wherever they seem to fit.   That’s not really what most people want.  GridLayout is pretty easy, but it can lead to unexpected results, because each element of the grid is precisely the same size.  Sooner or later, you’re stuck dealing with GridBagLayout. It’s complicated and the GridBagConstraints are non-intuitive.

In “Swing Second Edition” (see below), the authors present GriddedPanel, which uses a GridBayLayout, but with constraints that are easier to manage and understand.   The idea is that you often want a label and a control to be “glued” together, and placed at the same height as each other. You also often want the corresponding controls to line up vertically, with one another.  However, sometimes, you want a control to be able to expand a bit, if it’s larger than the other controls.

When using GriddedPanel, you use more intuitive methods than what you would use in GridBagLayout:

·        addComponent

·        addAnchoredComponent

·        addFilledComponent

 

Go and look at the source code online.  It’s at www.manning.com/sbe (Chapter 4).  And the book is a great reference for Swing in Java 1.4. Yeah, yeah, 5.0 is out, but you may take a while to transition to it anyhow.

 

Swing Second Edition, Matthew Robinson and Pavel Vorobiev, Manning  Publications Company, 2003.  ISBN 1930110-88-X

 

Online source
Source code for Swing Second Edition

Java IDE’s

Development Environments for Java

In the Java tradition, development environments for the language have been "bring your own".  Unfortunately, that leads to a great deal of confusion in the community about what the best tool to use is, or even where to start.

Eclipse is quickly becoming the de facto standard tool for Java development. While Sun and Borland and others are still providing IDE's, the open source Eclipse product is nicely integrated with JUnit and provides a fairly clean, easy to use interface, supporting ant and other plugins such as XML editors and more.

My personal opinion is that until the Java community settles on a tool, it will be difficult to compete with the .NET community, whose tool selection, while not mandated, is pretty universal.  Removing the confusion about where to start is a good first step in keeping Java in the running.