In House Software vs. Software Companies (BoIB)

Originally posted on December 4, 2007 on the internal blog:

Joel Splotzy has two new posts where he provides the transcript of a speech he gave at Yale. The basic premise is his career and how he got to be where he is.

It's quite interesting, and quite frightening. I've seen some of the places he's talked about when he goes off on the "80%" of programming jobs that deal with in house software.

That’s the second reason these jobs suck: as soon as your program gets good enough, you have to stop working on it. Once the core functionality is there, the main problem is solved, there is absolutely no return-on-investment, no business reason to make the software any better. So all of these in house programs look like a dog’s breakfast: because it’s just not worth a penny to make them look nice. Forget any pride in workmanship or craftsmanship you learned in CS323. You’re going to churn out embarrassing junk, and then, you’re going to rush off to patch up last year’s embarrassing junk which is starting to break down because it wasn’t done right in the first place, twenty-seven years of that and you get a gold watch. Oh, and they don’t give gold watches any more. 27 years and you get carpal tunnel syndrome. Now, at a product company, for example, if you’re a software developer working on a software product or even an online product like Google or Facebook, the better you make the product, the better it sells. The key point about in-house development is that once it’s “good enough,” you stop. When you’re working on products, you can keep refining and polishing and refactoring and improving, and if you work for Facebook, you can spend a whole month optimizing the Ajax name-choosing gizmo so that it’s really fast and really cool, and all that effort is worthwhile because it makes your product better than the competition. So, the number two reason product work is better than in-house work is that you get to make beautiful things.

One of the interesting things about this segment is the assumption that working on Products actually means that you're going to implement something that makes it better for your user. Sometimes, you make it better for your backend, which is far less glamorous than working on the frontend. Sometimes cool features get cut because, your customers aren't ready for it. I can think of several products which took several years to incorporate cool javascript gizmos, let alone Ajax gizmos because our customers were not ready for it. In essence, a segment of the customer base doesn't want the product they integrate into their online presence to look better than the rest of their online persona. There are customers who I've worked with who use older technology in 10% of their application simply because they aren't ready to fund the upgrade to the newer stuff.

It's unfortunately just not that simple in every instance.

Joel also comments on management styles when recalling his time at Juno:

Eventually, though, I started to discover that the management philosophy at Juno was old fashioned. The assumption there was that managers exist to tell people what to do. This is quite upside-down from the way management worked in typical west-coast high tech companies. What I was used to from the west coast was an attitude that management is just an annoying, mundane chore someone has to do so that the smart people can get their work done. Think of an academic department at a university, where being the chairperson of the department is actually something of a burden that nobody really wants to do; they’d much rather be doing research. That’s the Silicon Valley style of management. Managers exist to get furniture out of the way so the real talent can do brilliant work.

My first question here is, who decides if the investment is worth it? I suppose if you're a startup with a ton of angel funding, it doesn't matter if it's worth it to upgrade gizmo X. But if you're a software services company, it does matter. If contracts are written in ways where it really doesn't matter if you create gizmo X because no one's going to pay to upgrade to it, then you probably aren't going to do it. Someone has to manage that. It's not a chore in this case. In this case it's paramount to the survival of the company that allows you to create cool gizmos. Someone has to understand the customer and what brings in the coin so that the correct gizmo X Y or Z can be created.

Joel is a bit simplistic in his view because he makes the assumption that you're always going to do what's cool working for a software company. You will do cool stuff quite often, but in many cases, you aren't. You're going to do what provides the best return on investment for our customers. It's not always glamorous, but it's what keeps you employed. You need management because you need to sell product. Yes, managers should help to get furniture out of the way, but they also need to be smart enough to step in when the team is floundering and not making the decisions needed to be successful.

I do agree with Joel on one thing, however. In house software is not as fun as working on software services. Software services gets you working with internal and external clients. It's challenging and keeps a set of social business skills nimble that you might otherwise neglect.

Book Review - Managing Humans (BoIB)

Originally posted on December 3, 2007 on the internal blog:

About three weeks ago, I got an email from the Columbus Metropolitan Library that "Managing Humans" was available. It's taken me a while due to other commitments to finish it and this review, but here goes.

Managing Humans is the first book by Michael Lopp, otherwise known as Rands from Rands in Repose. It is an updated and edited collection of essays from the Rands in Repose blog that focuses on management, specifically managing software engineers in software companies. Lopp's resume is quite extensive, taking him around Silicon Valley and back through Borland, Netscape, Apple, Symantec and the failed startup. Through the diversity of these stops, he's come up with a set of tales about management and various personalities you encounter in the workforce.

If you've read Rands in Repose, you know that it's very snarky and pointed in its commentary. Managing Humans tones these two items down, which allows the book to be a bit more accessable to the masses. It's very funny and "too true" in many of its passages. Lopp gives many of his characters names which are catchy. You will probably find yourself saying things like "I know a Fez and his name is....", or "my manager is sooooo Organic".

The catchiness of the book allows it to disseminate quality information in a consise 200 pages and appeals to managers and their employees at the same time. For managers, the importance he places on the one-on-one is and communication is very compelling. While for the staff, the importance of understanding who your manager is and how he thinks is a great start on figuring out how to "manage" your manager to help hims succeed and make sure he knows that you are doing it.

When you do get the book, be sure to read through the glossary which contains many terms which you should probably know if you're in software engineering. My personal favorites:

• Synergy - A word used in close proximity to Leverage
• Leverage - A word used in close proximity to Synergy
  

If you don't find that funny, then, maybe this book isn't for you. If you do, go pick it up.

I highly recommend this book for ease of reading, entertainment and insight. It's worth a purchase and a place on your bookshelf for quick reference of how to manage people to help them and you succeed.

Using TestNG to drive "eyeball" testing

Second of my Best of Internal Blog (BoIB) series originally posted on 9/6/2007 and updated 11/14/2007

In my daily job, I do something that NBC would consider "green". I digress, but wasn't that an awful promotion last week? I help large companies save paper (and money) by presenting documents they would normally send to their customers through the mail. 99% of these documents are bills.

During my time working with various documents, I developed a tool based upon the testing framework TestNG. This tool allows us to look at a "cycle" of documents and test various things on each of them. We need to be sure that we're presenting each item to the user as it looks on their paper statement. It is most useful when we have a client who cannot generate an edge case test file for us due to the legacy nature of the billing system.

I had an opportunity to dredge it up again. The code for this tool is over two years old, but works relatively well with little fanfare. It grabs a list of identifiers from the database for each document, generates a URL to each document and then browses the HTML document using HtmlUnit. However, I recently found it has a new use.

The latest use is PDF testing. Some of our clients use a document format from IBM known as AFP. It's a high speed printer format, but it is similar to PDF in many ways in that it describes where on a page to display text. It is possible to generate a PDF document from and AFP document using a number of tools.

So how can the document tester help? Simple, create a special test class that is setup to archive the PDFs for each statement to disk.

Here's the test method inside TestNG (obviously I'm not repeating all of the bootstrappy type stuff that gets the URL to the document)

@Test(parameters = {"filePath"})
public void testGetPDF(String filePath) {
 List formList = theDocument.getForms();
 Iterator formIterator = formList.iterator();
 // 1st Form gets the PDF
 HtmlForm myForm = (HtmlForm) formIterator.next();
 HtmlInput myInput = myForm.getInputByName("viewDocument");

 try {
   Page newPage = myInput.click();
   WebResponse resp = newPage.getWebResponse();
   ByteArrayInputStream pdfStream = (ByteArrayInputStream) resp.getContentAsStream();
   ByteArrayOutputStream baos = new ByteArrayOutputStream();
   File pdfFile = new File(filePath + this.theDocumentID + ".pdf");
   FileOutputStream fos = new FileOutputStream(pdfFile);
   int count = 0;
   int data = pdfStream.read();
   while (data > -1) {
     count++;
     baos.write(data);
     data = pdfStream.read();
   }
   baos.flush();
   baos.writeTo(fos);
   baos.close();
   fos.close();
   pdfStream.close();
 } catch (Throwable t) {
   org.testng.Reporter.log("Throwable: " + t.getMessage());
   t.printStackTrace();
 }
}

Pretty neat! Now you get a directory full of PDFs that you can archive and ship off to your customer, or browse yourself. It sure beats a manual process of click and reload, and assures a proper test of using the actual application to generate the document. You could obviously save HTML or CSV files as well, but they can be tested using classes within the testing tool, which is obviously more efficient. This is simply making "eyeball" testing a bit faster.

Career Aspiration Killer #1 (BoIB)

First of my Best of Internal Blog (BoIB) series originally posted on 8/23/2007:

You Tube.

Right around the 4:21 mark in this clip:

Sure it's seven years ago...but that kisses any thoughts of political office away doesn't it? :)

Now if I could only find those clips of me at wrasslin events from back in the day.