It's a Job Title

I read two blogs asking whether we are engineers or developers. Their argument is that computer science does not produce engineers because we don't have hard and fast rules for what optimally solves a given problem. Engineers, to them, are people that really deal with the physical laws of the universe when producing a given object in a predictable, mathematically provable way. They have interesting points:

1. Jeremiah Clark, “Jeremiah Clark's Blog : Are Software Developers Really Engineers?,” http://blogs.msdn.com/miah/archive/2009/02/08/are-software-developers-really-engineers.aspx.

2. Scott Palmateer, “Software Alchemy - Scott Palmateer,” http://scottpalmateer.spaces.live.com/Blog/cns%21144A1BAAB1016256%21491.entry.

First, there is plenty of engineering in software development. We don't always see it, especially when we are working within generic frameworks, because the execution behavior of the framework changes the execution behavior of our code and thus removes one of the tenants of good engineering: predictability. Predictability in the physical world is being able to determine the crisis point of a given object well ahead of the crisis occurring. We can predictably tell exactly how much weight a given box made from a given material can contain before it bursts. In fact, you can look at the bottom of most generic brown card board boxes and see the burst point clearly labeled on the Box Manufacturer's Certificate by some box standards organization. Software development often doesn't have that level of predictability as the developer moves further away from the raw hardware.

A current Java based web application running Seam (Richfaces, JSF, EJB 3, JPA/Hibernate and more) on JBoss has very little predictability in my opinion. I believe this to be true because I watch how much injected and generated code is created as my application runs. I can watch my call stack grow as the injected and proxied objects get generated that manage a single request's life cycle to get to my first bean, let alone drill all the way down to my SQL server. I cannot predict exactly how much code will execute between the servlet that is actually processing the incoming request to my bean and I have no idea how long it will take to execute that code. I am left with the hope that it will perform well and that my code will execute in the way I had expected.

There is a concept called "programming by contract" and another "programming by coincidence". Programming by contract says that someone writes a rigid specification for a given API and I write my client code using only the specification as my guide. It also means that the results of any call have been laid out in the specification such that I can trust that with good data the API will respond with a valid result and with bad data that the API will return a specific error response. Programming by coincidence is when you call an API method and set a breakpoint on the line, examine the results and write the rest of the code to handle that response. The problem is that many specifications are either inaccurate or wrong so you end up having to write some measure of code that relies on programming by coincidence. Programming by coincidence almost always eliminates predictability because the behavior of the API or framework is not guaranteed and thus not predictable.

Predictability increases as you move closer to the hardware. You know precisely, or pretty accurately, what your low level language is going to load in order to execute your application and the overhead of those components. The fewer and lighter the external components are, the more likely you can reliably predict performance and side-effect impact. Higher level languages, like Java with some frameworks, don't have the same level of predictability because you can't always tell what the application is really going to load and how those components will effect your application until you start running it.

Note: I love Java as a development language and I couldn't accomplish a giant web application in a timely fashion if I wasn't using some kind of framework. I know though, from a purely scientific perspective, that the more I bring in from the framework, the more risk I take on that the component will not execute or perform to expectations.

Second, software development is about applying design and implementation principals to a specific situation and those principals may not work in other similar situations. MBA students talk about case studies where a professor presents either a real or fictitious scenario to help students to understand a decision making process. The professor may go through several different case studies that may have similar scenarios and vary enough to result in different outcomes. We have the same kinds of problems where one variation in the goals of the project can change components and the project's schedule.

Let's say you have to write a log file reader to extract all the SQL queries generated by Hibernate for two different companies. Company A wants the reader to run though at least 10,000 lines per second and Company B wants 5,000 lines. Company A wants to see the changes in real time and B wants to run through the log at the end of the day and produce a single report. So far both companies could probably be served by the same application. Company A says it wants to store all the output in a database, Company B wants it in memory. Finally Company B says it wants to support IBatis queries and to filter out certain queries. Now we have some design differences that may be significant.

We can see that the reading and translation of the queries is largely the same until Company B wanted to support more than one ORM. One design may take a polymorphic stance and try to generate objects that specifically read each kind of line. Another possible design is one where there is simply a branching statement that just runs the translation code without using a specific object for the kind of log statement. The storage mechanism may require something innovative to get the database updates to meet its performance needs while Company B may require something far more simple. You want to reuse as much code as possible, so how do you do it?

You have a lot of different options and any one of them is probably just fine. You may even decide that your hourly rate is greater than the cost of using something prepackaged so you just buy that application, configure it and then work on something else. You may also sit around and write something in python, perl, Java, C++ or any one of your favorite languages. Tell the same scenario to another developer and he may come back with an entirely different approach and it still meets the same requirements. One approach will be better than another in some respect but may fail in others, thus software becomes a negotiation process in dealing with the trade offs to accomplish the goals set by the customer.

Third, it's a job title damn it! So one company calls you a software engineer and another calls you a software developer and you think it matters? You write designs and implement code in the same way in both places. I write web applications all day and I argue that we mostly find ways to integrate components and systems together to build interesting apps. There's hardly any really innovative code beyond just making the web application work. I half expect to be retitled from Web Architect to Web Cobbler. I could probably resole your shoes while I'm at it.

Job titles are pretty nutty when you really look at them. One company's Software Engineer 4 is another company's junior software engineer. I know this from experience in that one previous employer ranked employees in pay bands so a software engineer made X dollars which caused him to be in the fourth pay band so I was a Software Engineer 4 even though it was an entry level job. My Magic Missile improved remarkably when I became a Software Engineer 5.

You see Principal and Principle Software Developer/Engineer on the job boards all the time. One means that your a very senior engineer and the other means you have a good moral compass. My favorite job title was a guy from Sun that was known as a Computational Theologist.

You have to look at the job responsibilities to understand whether the title is meaningful.

Now I'm not saying to ignore job titles when looking for a gig. Job titles actually do matter though some employers and pundits say it shouldn't. A senior job title should mean senior responsibilities. The title opens doors later in your career and we shouldn't discount titles as a result, especially when they show a track record of increasing responsibilities. That means your employers trust you to lead or do important things and future employers will like that.

Sometimes we get the chance to change a title to something goofy or funny. Grand Coder, Debugger Extraordinaire, "He that lurks within the kernel", Jackass, Meat Calculator, Chief Computer Scientist and so on may sound great but are probably less advisable if you want people to quickly understand what your last job was without having to go into obnoxious detail. While I chuckle that I'm a software cobbler, I won't be changing my title any time soon.

Losing Routine

English has this wonderful term called "Senioritis" where US high school seniors often give up on hard school work in the final days, weeks or months before graduation. They figure they can coast to the end and do just fine. There is an unspoken wisdom to the pressure valve opening, especially at the realization that childhood is supposed to be over and now you must go off and live your life. Adults know that the real transition is when you leave student academia for work and that transition may not happen for several years.

Software projects can go through a similar senioritis. It happens near the end, after some major milestone has passed and things go from frantic to calm, like the sea after a storm passes. There is a lot of churn and the flaws and damage are laid out for all to see, but the frantic pace and long hours are mostly over. I look at these senioritis times with a sense of cautious optimism.

I'm cautious because some people become sloppy and stop doing the things they have been doing for months. My favorite change is the sudden disappearance of the steps to reproduce a bug. I may get great bug reports with detailed steps to reproduce the error and the suddenly I get bugs from the same people that say "Dialog doesn't work" and I go into that dialog and find it does work. I try two or three more things but the error doesn't manifest itself. The normal thing is for the developer to mark the bug as not reproducible and wait for QA to reopen it after adding some new step or some missing clue.

I'm a stickler for following procedure and protocol. It can drive some people bonkers that I want nightly builds, comments with commits to source control, bug numbers with commits to source control, steps to reproduce bugs and the resolution comments for that bug to be something more than "fixed" unless it was remarkably easy like renaming a field's label. It isn't unusual for me to visit or email a staffer asking them to stick with the protocols we have been living with.

I know, someone is rolling his eyes saying that I'm just a procedure pushing dumbass. That I'm enforcing procedure rather than facilitating development. Some times the comments in a bug are enough to tell the developer how to fix a bug with no need to have steps to reproduce. Those people are correct up to a point. Common sense does kick in because we don't need to have steps to reproduce an error when we are talking about changing the label on a field though the change may be tracked in the bug tracking system. The point is that we follow procedure in the big and little things alike so that everything works consistently.

Consistency and reproducing consistency are valuable for limiting miscommunication. Skipping protocol means that details are lost and those details may need to be found again. We have to trudge through the base work to get back to the original point. Skip the daily builds and you don't know when a major build change occurred that breaks the product and prevents the next release. Skip documenting the steps to reproduce a bug and other people on the team can't figure out what is going on, or worse: a developer reproduces what looks like the bug but he really fixes an entirely different bug that exhibits an identical looking error.

A project experiencing senioritis sees the procedures breakdown that brought you so close to the finishing line. As details are lost, so are the hours before the project is done. The pressure comes back to the old frantic pace, rising just like the waves on the sea and pretty soon you find yourself in a storm in the hours before releasing the project. The moral of the story is to stick to procedure, be consistent throughout the project and don't let normal everyday processes slip until the project is done and shipped.

Do I Need a CS Degree to be a Software Developer?

A degree in almost every field only indicates that you have met a minimum set of requirements. It is not an indication of proficiency in the practical application of the knowledge you gained through your degree. The degree is still valuable though and we should not underestimate its worth but we should understand its limits.

First, great software developers come from all walks of life and do not need to have a formal education. We are in one of the very few professional fields where this is true and accepted. Most other fields do not provide people with the opportunity to self-teach the subject matter. For example, you probably don’t want a surgeon who has only read about medicine but never practiced it. Software development has a low barrier to self teach in that you can buy a computer for little money, pick up a few books and start writing code. That code may be terrible at first and you are not jeopardizing anyone’s life either.

Second, really smart and dedicated people have the ability to learn how to be software developers and are generally encouraged by the community. These people can take the time to learn the craft and become highly proficient. Then get a job and hone those skills. This is true of people with and without formal academic training.

Third, people with a degree in computer science, or in a multitude of other curriculums that require programming, are not necessarily going to be better programmers than the self taught. It is a matter of dedication and aptitude to the field. There are plenty of ridiculously bad software developers and CS graduates out there. The fact that they got a degree always frightens me.

Fourth, graduating form a top-tier computer science program does not mean that you are going to be a good software developer. Some of the top-tier schools use teaching languages rather than practical or rigorous languages, such as Java and C/C++. Practical languages get you a job if you are proficient. Rigorous languages, provided they are rigorous in the use of the machine rather than just having an overly complicated syntax for simple operations, teach real data structures and how to truly control the machine.

The value of formal computer science and programming courses are that the exercises and the reading materials are different from those more commonly available to the rest of the public. The books you generally find in Barnes and Nobel have a goal of getting you programming or solving a specific set of problems in the shortest time possible. These books don’t always go into the theory or the “why we are doing this” bu instead focus on how to do it. 

That’s what the text books and classes are supposed to do. The experience of guided instruction, programming exercises and text explaining theory are supposed to teach why we do the things we do. The implementation, or the how we do it, is an entirely different problem that is often easier to solve.

For example, I could ask you to write a Java program that takes a paragraph of text and displays each sentence with a count of the spaces within it. It takes about ten minutes to write the code. It isn’t hard at all. You can find out how to do it by simply searching the web.

Now, let’s say that I want you to perform string replacements for any expression within the paragraph bounded by curly braces. Then let’s say that I want you take what is within the braces and determine if it is an arithmetic expression and replace the expression with its results. The example paragraph may have a line that looks like “3 * 10 = {3*10}” and the output is “3*10 = 30”.

Can a person without a formal education in computer science do this? Sure, but pretty much any CS student can do this as a result of just the required courses. Especially any graduate student who has taken a compiler design class. 

The problem for the self-taught is that the commonly sold texts don’t go over these subjects very heavily. These books often cover an existing API or a technology that makes it simple to accomplish the task. It’s the difference between knowing how to use Apache Velocity vs writing Velocity.

Can the self taught learn these things too? Of course they can! The question is whether you will ever be exposed to the material and whether you will have the depth of knowledge that  one gets from a formal education in a subject. This impacts how far you will advance in your career and the kinds of problems you will be asked to solve later. 

Just to be clear, I know many non-CS software developers who are great architects, CTO’s, VP’s and leading software developers and they all have the same depth as a CS graduate student if not more. The difference is that they had to seek out the information rather than having it handed to them. Their dedication and intelligence is what led to ever more challenging tasks and their success. I have known a large number of CS and non-CS developers that were inept too. Their lack of dedication or intelligence led to their mediocrity and relegated  then to equally mundane tasks.

Being a Developer During a Recession Part 2

A year ago I wrote some thoughts on preparing and weathering a layoff. I reread it this week after meeting a fellow in a hotel lobby. I was there with my wife and son because we had lost power in the recent ice storm that struck the north east. We lost power for several days and needed to find warm places to stay. He was there for the same reason.

He was a tech writer for a Massachusetts company for ten years. He had been laid-off just a week ago. He was going through loss and anger at being forced to go away. His income was taken away along with pride and purpose. You could see the pain on his face and it struck a chord within me.

My layoff was not an easy time, especially the months just after the layoff, because I felt terribly betrayed, bitter and lost. It was winter and its hard for me to be cheerful when the days are short, grey and cold.

I lived in a condo about an hour north of Boston and fortyfive minutes away from my old job and the friends I had worked with for nearly three years. I was single and a little overzealous in my love for writing code, so my work became my life. One day I was evicted from my life and things felt pretty bleak.

I watched in 2002 as every other department had significant staff cuts. The development team wasn’t going to be touched because we were in the middle of releasing a “game changing” product that would seal the company as the leader in its space. It didn’t take a genius to figure out that layoffs in engineering would follow the release. It was of a question of when it would happen rather than if. I stopped spending and saved everything I could except for going out for dinner and drinks with friends.

The year leading up to my layoff was tough. Everyone was working long hours and weekends for months on end. Vacation time had been canceled. Getting more than one or two consecutive days off was difficult.

I was a principal developer and had several critical components to develop. I was always writing middle-tier core code that nearly every other component called. I designed the entire security component and wrote all of the method level security methods. I also wrote the interface and all the components for our content management system, which also included a fairly complex collaboration model that managed an editorial process for content publication.

Writing so much core code gave me a false sense of security. Who would seriously layoff the only developer that knew both security and document management. Getting rid of that developer would be a huge setback to any project. Of course, you have a lot more time to learn what that developer wrote after you release the product and have six or eight months before your next release.

The first round of engineering layoffs occurred in October of 2002 after a September release. We all knew who was being laid-off too. The management team scheduled reviews and raises for all the employees that they were keeping. There were eight people that didn’t have reviews scheduled. It was terrible to watch one of my good friends break down and cry every day for two weeks as she waited to be let go. She was the sole income for her family of of four. They were kept on for about three weeks before they were let go.

The second round consisted of a couple of great UI designers and a few people in another office that I never met. The UI designers built a really amazing user interface and kept a product with dozens of web pages looking cohesive and made the work flow from one task to the next logical and elegant.

Round three had lost five people, myself included. There was a product manager that was pushed out. All five of us were hard working and had made significant contributions to the product.

I found out about my layoff about a week ahead of time because the VP of Human Resources left a memo on his desk with the five names and a helpdesk guy was called in to work on his laptop. The helpdesk guy saw the names and told me I was on the list. I found out in the parking lot while another friend of mine and I were heading out to grab dinner and drinks. That was a night of very heavy drinking.

That following Monday the VP of Architecture called me into his office. He wanted to go over the document management system and document how it worked so we could teach the other developers how to work on it and improve the system. I smiled and said “Ok, but if you are going to lay me off, please do it on a Friday. I don’t want to have to drive all the way down here on a Monday and then drive back.”

There are statistics that show that suicides occur more often if you lay a person off on a Friday than on a Monday. I wasn’t going to commit suicide over that job so I was planning my weekend ahead of time. I had an idea for a new product and just needed time to write it. I knew I would have plenty of time to work on it now.

I spent the week writing up documents and having daily talks with the VP of Architecture and his chief architect. I liked both of them. It was hard knowing that I wouldn’t see them again. The meetings would go on for hours and then I would work on the document. In the middle of the document I wrote something like:

“I’ve spent this week writing all this documentation but I know you are not going to actually read it. It is really pointless for me to be doing this and if I drew some diagrams you may have a shot of comprehending the mess you are in. Unfortunately, the only tool I has is powerpoint, which isn’t known for its high quality diagraming technologies. Good luck!”

That was the extent of my sabotage. I finished everything on Thursday and went home knowing that the next day was to be my last.

I got in around eleven AM and asked my friends if we could go to lunch. I mentioned something that it was important and meant a lot to me. I told one of my friends that I was going to be laid off that day and he thought I was nuts until the VP of Architecture swung by and wanted to meet with me.

I wandered into the VP’s office and was handed my package, which I read through and tried to keep calm. I was gasping for air every time I spoke. I could hardly get the words out when I needed to ask a question about health insurance, severance or my remaining time off. My heart was pounding so hard. Then I got up and asked if I could say good bye to my friends. I was allowed that honor because I had put in so much time and effort, everyone else was walked out the door with little time to clean up their desk.

I swung by a few desks after lunch and said my goodbyes. I went home and drank a bottle of wine and watched some bad science fiction movie. I had to watch it a second time the next day because I didn’t remember anything from the previous viewing.

I started writing code that Monday on an application analytics platform. I wanted a tool that could tell me the features and the order that customers executed in a given product. This would tell me which features customers actually cared about and would let any developer prioritize the heavily used features over the rarely used. I wanted the reports to be web accessible. I needed a way to collect the data from an arbitrary application and dispatch it back to some import server that would dump the data into a database. I needed an analytics engine to convert the raw data into summary information. It was something big enough to keep me really busy.

It was a great project for me in that I didn’t know UI development at all but knew EJB 2.0 inside out and was also decent with database work. I spent a year writing code and living off the money I had saved.

I buried myself in work for weeks. I would get up at around eight AM with no alarm, eat breakfast, write code till two PM, shower, eat, write code until eight PM, eat, watch a movie and go to bed. I edited my spending habits to food, utilities, healthcare and mortgage. I had to cut the house cleaning service. I cut beer and going out for meals. I stopped buying stuff almost entirely except I did buy a new desktop computer to build my new application.

I kept in touch with many of my friends via email but I was pretty dedicated at developing my own project. It’s not entirely true that I was dedicated. I was incredibly hurt by being laid-off and the way I dealt with that emotional pain was by hiding in work of my own design. I was angry at the company where I had sacrificed and worked so hard. I had given up weekends, nights and even dental appointments because I felt needed and couldn’t let the team down. I had hardly dated or done anything with people that weren’t in the company. It had become my life as many of us would go out to dinner or hang out together regularly. I missed my friends terribly.

I worked on my project for about three months before I hit the wall. I looked like a wreck. I would shave only every couple of days. I was dressing as a flannel clad Hugh Heffner though I wouldn’t go outside in that outfit. I hardly went anywhere except to the supermarket. Most of the light bulbs were burnt out but I knew where everything was even in near total darkness. Only the kitchen was kept up lighting wise. I did keep the house pretty clean though.

Things got to a point where I couldn’t code well anymore. I was getting wrapped up in simple problems and looking for really innovative and exciting solutions. I realized that the solutions were not practical anymore. They were complex and strange but looked like they would work really well. I was losing or had lost perspective. It was time for a vacation.

I didn’t go anywhere. I stayed at home and cooked. I was a terrible cook and that’s why I ate out so often. I ate out every night before the layoff. Was it expensive? Only marginally so since factoring the cost of electricity, food, water and cleaning that dinner out only cost me a buck or two more per night. That came out to somewhere between 30 and 60 dollars I could save if I cooked at home. I cooked dinner every night and ate the left overs for lunch.

I ended up going to the supermarket pretty much every day. The idea was that I only bought what I could carry in one trip from the garage to my kitchen. I also didn’t know what I would feel like eating from one day to the next. It felt better to be around people anyway.

I watched “The Recruit” one night and an idea lodged into my head that I hadn’t been reading very much fiction in the past few years. I wanted to read some Kurt Vonnegut because of a reference in the movie to ice-9. I was hoping to cheer up by reading his works. I got in the habit of going out to lunch and reading while I was at the restaurant. I was able to go to a different restaurant pretty much every day and that was fun. I cheered up a lot, especially after changing out all the lightbulbs.

Spring was rolling in. I went back to hammering on the keyboard to build my application. There was a UI, a middle tier and a database that were coming together nicely. Writing the UI is rather difficult for me still but that’s where UI development really started. The product was almost in a demonstrable state.

My schedule changed a little. I was still up at 8, breakfast, shower, Babylon 5, code, lunch, code till 7, cook, eat, movie and bed.

Reading Vonnegut was brining me down so I thought I would cheer up with a new author. I wanted to read something that had influenced the way literature was written. I reread Jack Kerouac’s “On the Road”, which is still one of my favorite books. I started reading Hemingway and read three of his novels before stopping. Why? Why did Hemingway’s chicken cross the road? To die, alone, in the rain. That’s why. Don’t read Hemingway if you are feeling down.

I was feeding data into my application using some test cases and now I wanted to get the system more automated. I used Java byte code injection to instrument a target application. Getting injection working is simple but getting it to work in a wide range of applications and perform was far more difficult. I spent a bit more than a month getting everything to right.

Looking for a job was also a big aspect of my life. I would hit the web and visit a number of job sites like HotJobs and Dice. I also talked to a recruiter and worked with him. I had only one interview in six months. It was with a CMGI company. The company went out of business a month later and sold off all its assets. All the employees were out of work.

You could go on to HotJobs and do a search of Java development jobs in the summer of 2003 and get back zero results in the Boston area. Right now you can find around 110 on HotJbos and 438 on Dice. I kept looking and submitting resumes to meet unemployment insurance requirements, but there was no chance of actually finding a job at that point. Congress kept extending benefits out to a full year. I thank God for that.

A friend of mine and I decided to launch a company with my product and look for some kind of financing. We met with SCORE, which was a complete waste of time. They are fine if you want to start a restaurant but they are out of their league with tech startups. Things have changed in the way software is developed, financed and sold such that their experience is not generally relevant.

We did get a few chances to pitch the idea to investors. It didn’t go anywhere. They would nod and think that it was an interesting idea but they were not interested in investing. All the entrepreneur wannabes should take note of this one statement: Investors invest in people, not ideas. We did not meet their vision of investment worthy individuals.

I was not put off much. I kept working because there was nothing else to do. I did spend more time during the summer goofing off though. I had Friday lunches on the deck of this restaurant and have a beer too. I decided that I could reintroduce beer into my nightly diet.

That summer I got a number of charity requests. Calls from my old college asking for money. I told them that I was on unemployment and couldn’t afford a donation this year. They suggested that I go on a payment plan. How can a person even suggest going on a payment plan to fund a charity like a college when you are concerned with paying your mortgage, healthcare and being fed? I haven’t talked to the college since.

I put up a dating profile on Match.com that August. I changed the profile’s “about me” section about once a week hoping that I would eventually write something interesting and get a nibble. It worked too, I was having a number of email conversations and that was fun.

Fall started and I launched the product on the web. I was not about to give up on the idea so I just took a different direction. Nibbles? No, I could count the downloads with my fingers. Still, it was getting out there and every download gave me hope.

In October I traded emails with this one gal that winked at my on Match.com. She was a little goofy, brainy, had a great sense of humor and she stuck by me as fall turned into winter. Our dates were so fun. She would go to her work and I would keep working on my project. Life was becoming so much better.

January marked the end of unemployment insurance. I had plenty of savings still so I wasn’t very worried. I was emailing more resumes and kept developing the project. I had a few interviews and they actually downloaded the project. The UI was pretty bad looking back at it, but I was getting back into the groove of being interviewed and it helped get me in through the door.

One morning in April I saw a job on Craig’s List. I put in the resume and went from my home office to the basement to do some work. I got a phone call from the recruiter I sent the email five minutes to and she was scheduling an interview. I got the job and a surprise: I got my old salary after being out of work for over a year! It was a miracle as far as I was concerned.

Working on the project kept my skills sharp. I had gone deeper into a number of technologies and worked with many new ones. It was wonderful to have a new job thanks to the project.

I didn’t stop with the project though. I showed it to this one guy and he showed it to another and pretty soon we were raising money. It took a year and we raised $750,000 by the end of the Summer of 2005. It was huge. He was the key, he was going to MIT Sloan School of Business and he made all the financial connections. I kept writing code.

My girlfriend and I got married in October of 2005. We went on our honeymoon and came back to my new company.

The experience of being laid-off was devastating at first. It was so gut-wrenching to be evicted from my life that I can’t put it into words still. I can’t explain the anger at having given so much and then be told that we don't need you anymore. Being laid-off is a crueler thing than most people can understand.

It worked out in my case though. One could argue that it was the best time of my life and that only the first three months were really bad. That actually isn’t true as I still reflect on it with bitterness and I’m not sure I’ll ever be free of it.

We read a lot of advice on how to keep your job during a recession too. Many say to be the critical employee that the company cannot afford to layoff. Companies layoff C-level staff all the time and they are supposed to be the most critical employees in the company. Only a few companies will see the value of a developer being greater than some executives.

I have only four pieces of advice. The first is to save your money. The second is to find a way to keep your skills sharp. The third is to find a purpose to drive you forward everyday. The fourth, and most important, is to be thankful for what you have because there are those that have far less.

GUIDs as Primary Keys or How to Walk Into an Argument

I generally work on two kinds of projects: the big enterprise web application and the tiny startup web application. The requirements and processes for building these two projects are distinct. For example, the database in a big project could easily be Oracle or DB2 while a tiny or mid-size project may run on MySQL or SQL Server. Other differences include hardware and staffing resources.

Before we get too far, I should make a note about the above databases. I personally have yet to encounter a project that cannot be implemented using MySQL. I have built analytical web applications running hundreds of millions of rows in a single table and it worked and performed well. There are limitations in tuning but generally I have found some level of snobbery with the DBA’s thinking that MySQL is just a toy DB. A word of caution to them is that Toyota was once seen as a mediocre, unreliable, rusty piece of junk and now it is considered one of the most reliable and financially stable auto makers in the world. Things really do change over time. Back to the main subject.

Big projects often have larger budgets, more resources, more requirements and often have a longer development cycle. That longer development cycle may include more time to understand the data model and the production environment and thus produce a executable design.

Small projects often have a small budget, fewer resources and may have much less planning. These projects may also be cash flow constrained, meaning that you want to spend as little per month as possible while still delivering a service that customers will buy.

Databases and primary keys come into play when you are working with a small project that may become big and outgrow its hosting needs. Moving a physical server is relatively easy provided that you can schedule some downtime. You may end up having to replicate the database on a new server and bring up the new server at the new hosting site. There will almost certainly be some data reconciliation process after the transition form the old server to the new.

A bigger problem occurs when you are really small and trying to go from one web provider to another. You may have a Virtual Private Server (VPS) at one hosting provider and have to migrate to a dedicated server with a new provider. This migration process is more difficult and requires more downtime.

Its more difficult in that replication is not an option. Some will argue that database replication is tricky unto itself. However, to me there are only a few things more painful than exporting a database and then importing it somewhere else. The easiest migrations used a GUID as the row ID. This is especially true when I’ve had to merge two or more active databases.

I was planning on writing extensively about the virtues of using a GUID as a primary key and then I read the following posts:

   1. Brian Aker, "Brian "Krow" Aker's Idle Thoughts - Myths, GUID vs Autoincrement," http://krow.livejournal.com/497839.html.

   2. Jeff Atwood, "Coding Horror: Primary Keys: IDs versus GUIDs," http://www.codinghorror.com/blog/archives/000817.html.

   3. Mike Malone, "Database Design: Choosing a Primary Key - I'm Mike," Blog, I'm Mike, http://immike.net/blog/2007/08/14/database-design-choosing-a-primary-key/.

   4. Jimmy Bogard, "Designing primary keys - Jimmy Bogard -," http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/06/04/designing-primary-keys.aspx.

   5. Joe Celko, "Identity Vs. Uniqueidentifier (Newbie question) - microsoft.public.sqlserver.programming | Google Groups," http://groups.google.com/group/microsoft.public.sqlserver.programming/msg/6d61dbf80d6f0fb6?hl=en&lr=&ie=UTF-8&oe=UTF-8&rnum=14.

   6. Jimmy Nilsson, "The Cost of GUIDs as Primary Keys," http://www.informit.com/articles/printerfriendly.aspx?p=25862.

   7. Kenneth Downs, "The Database Programmer: Database Skills: A Sane Approach To Choosing Primary Keys," http://database-programmer.blogspot.com/2008/01/database-skills-sane-approach-to.html.

   8. Peter Zaitsev, "To UUID or not to UUID ? | MySQL Performance Blog," http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/.

Jeff Atwood’s post is particularly interesting because of the huge number of comments and most of them are against the use of a GUID as a primary key.  The most common reason against GUIDs has to do with large tables in that search performance degrades more rapidly than autoincrement or sequence integer IDs. Some of the other posts argue that the degredation is not significant enough to warrant concern.

Others argue that the primary key should be an integer but the end user should see a GUID as that makes it easier to obscure the layout of the database. I’m not sure I buy that argument since it should still be pretty easy to find a given row using that GUID. I think this developer was really trying to create a level of abstraction from what a user may bookmark from something that code could efficiently work with. The strategy would allow the developer to change his primary key without impacting the user. However, it would seem reasonable to ask how much benefit there really is to having both keys when the GUID alone is enough to do all the work?

My thought on this is that the GUID is slow to look up, but once it is loaded you have the object’s real ID and hopefully it will load faster in follow-on queries using that numeric ID. A smart developer may also ask why someone would be loading a record once by GUID and then reloading repeatedly by numeric ID. Shouldn’t the original load be enough for most applications?

Many of the posts have a shared viewpoint that GUIDs do not significantly impact performance on small tables but fail to say how many rows makes a table small. They often agree that DB merges are easier using GUIDs.

My personal viewpoint is that I have not measured a significant enough performance impact to dissuade me from using GUIDs in a project that I know will be migrated to a new hosting provider. I think it is fair to use autoincrement integers or sequences when you know your database will never have to be merged or migrated and on tables with more than 10 million rows though the quality of the server may increase the number of rows.

This opinion takes us to the second part of the time: How to walk into an argument.

Computer science, like all of science, allows developers the freedom to form an opinion and later a hypothesis about how something should work or be done. We have opinions on nearly every subject and some of them are polarizing. A GUID as a primary key is one of those polarizing subjects. 

I have witnessed an explosive argument between developers arguing for and against GUIDs and both of them citing anecdotal evidence only that there is a performance issue. I have personally been involved in a discussion where the other person dismissed the very idea of GUIDs without further discussion. That same project had a significant delay as a result of a data migration problem that would have been entirely avoided had we used GUIDs.

As I said, I was planning to write more extensively on the virtues of GUIDs and then I read the other articles and realized that this is not a back-and-white solution. It is a solution that is ideal in only some situations, just like a hammer is only really useful when driving a nail or banging something into a new shape. It became clear that this subject is highly contested and would become a serious argument.

Walking into a huge discussion or argument over design principles is amazingly easy. One of the hardest things to overcome is that generalizations are often very dangerous without empirical data to back it. Only by taking risks and testing the approach, using real data, can one rule out the use of a particular construct or strategy within a web application. Thus many seemingly unorthodox approaches may actually be valid within the conditions of the application.

My conclusion is simply that GUIDs as a row ID may be perfectly reasonable for your application. It may cause some performance degradation, but the degradation may be insignificant. The only way to know is to test it and compare the performance of the key to a more common numeric key and then balance that against the requirements of your application. The only thing we should not do is dismiss the approach without first confirming that the conceivable issue is a real issue.

Can I Just Change Jobs?

The topic of "Love it or Leave It" from Jeff Atwood is an old one that pops up every year. See these two links:

1. Jeff Atwood, "Coding Horror: Programming: Love It or Leave It,"http://www.codinghorror.com/blog/archives/001202.html.

2. Joel Spolsky, "The Joel on Software Discussion Group - Thinking of leaving the industry," http://discuss.joelonsoftware.com/default.asp?joel.3.718003.14.

Its the notion that software developers are so passionate about coding that they would do the work for free and that anyone who wouldn't is a bad developer. I, after a lot of reflection, agree with this up to a point. I code in my spare time on projects of my choosing because it is something I am interested in and I find it relaxing. It's recreational programming.

There is a misguided notion that coding and software development are the same thing. Software development is a process of requirements gathering, designing, refining, developing, debugging, refining and deploying for the purpose of making money or for academic research. This process often occurs within the scope of one or more teams that have their own hierarchies and procedures for decision making.

The problem with the "love it or leave it" attitude is that it doesn't separate the job from the task. The task of coding is often enjoyable provided you are working on an approach that you don't fundamentally hate. Hate is a strong word for the situation, but most developers eventually get stuck implementing something that is just a horrible idea but we're doing it anyway because we were told to do it. I get really cross in those situations because I feel like I'm failing my own standards even though I am doing what I am told. I feel like I also failed to explain my viewpoint in a persuasive enough manner.

The job of software development can be terribly frustrating depending upon the team and organization. You could have a dictator for an architect who never listens to your designs. You could have a miser for a VP of Engineering or CTO that expects his employees to work 60 hours a week. You could have the most dull job in the world and the code you are writing is not challenging or even interesting. You could have five bosses that compete for your time and get angry when you work on one of the other boss's tasks. You could have three or four cliquey teammates that create unnecessary drama in the workplace. You could be an architect but not have buy-in from the CTO so nothing you design ever gets implemented. You could have a nutty team lead that always wants to take shortcuts in code rather than really fixing a problem. You could have an HR policy that requires a timesheet that describes the work you performed in 15 minute increments. You could have daily standup meetings that take an hour, accomplish nothing, occur at lunch every day and the next round of meetings begins at 1pm. Your manager may take a nap, with the lights turned off in his office, while the rest of the team is on hour 12 of a 14 hour day trying to meet a deadline. Your software developer job could really be a miserable thing.

How many people have seen one or more of the above in their own workplace? I've seen all of these actually happen! A few of them have happened to me. Having five people assigning you tasks and making them negotiate for your time is very trying. That sleeping manager really amazed me but I already had a new job and just wanted to get out of there.

We are fortunate in many areas though. We generally make much more money than the average person. Our salaries plateau early in our careers compared to others, but the plateau is often well above the average pay in your geographic area. We often work in comfortable, climate controlled buildings. We almost always get good benefits like health care, some form of retirement and paid time off. We often get to work on challenging problems that test our abilities. We often get to work with smart people that often care about their work. Many of us have a lot to be thankful for.

Who should we be thanking? Is it our employer? How about teachers? How about team mates? Maybe it's our parents that encouraged us? Our spouses and our family? God? We got to where we are by working darn hard and through some people that supported us. Our job is not easy and not everyone can do it. We give up a lot of free time to master our craft and we often have jobs that require longer hours than almost everyone in the company. We are passionate about our work and expect to be treated and paid well too. And we are thankful to those who support us and stick with us when we are working.

Loving your job and loving coding are two very different things. We cannot sit and judge a person's situation from afar and say that he should be thankful for his job and is whining. Sometimes a job just sucks and it's time to move on. Sometimes we need a reminder that other companies are different and there are better projects, better places and better teams.

There are plenty phenomenal software engineers who are tired of the job and want to try something new. A good friend of mine left software development to become a photographer. He is easily the best software developer I have ever worked with and he walked away from the craft entirely. He codes just for the fun of it, occasionally writing the odd sudoku puzzle solver and thus taking the joy out of the puzzle entirely and moves on to something else. Is he a bad developer? No, he's just done and ready to try something new. How many people do we know that came to software development from some other field? How many of them are good at it and do we call them quitters for leaving the field they started in?

We sometimes take the viewpoint of "code above all else" but we see many that want to have a good job and be able to enjoy other aspects of life. Many of us are naturally inquisitive and need to apply our minds to many different disciplines, which is where we get the art in the "Art of Computer Programming." The art, by Knuth's definition, is the application of many different disciplines in order to code great applications. You need to learn a little accounting if you are going to write Quicken and you need a little expertise in photography and editing if you are going to write Photoshop. We learn to work with others to build a great application. We need to be more than just good at writing code to be great as software developers.

But some of us are tired of all the things that go along with coding as a part of a job. And some of us go off and start our own company because we want to code on our own terms. Others move away from jobs that require coding and become architects, team leads, CTO's and CEO's and yet we don't call them quitters or complain about their lack of coding commitment.

The "love it or leave it" attitude helps no one and labels too many people as not committed enough and opens us to exploitation by our employers. It confuses the job of the software developer with the fun of coding. We code because we love to and we work because we have to pay bills. We are lucky that our work is often on of our favorite things to do, but we are equally cursed when our work demands too much of us and our family. Many of us do not lead lives of quiet desperation but many of us are pulled between the needs of our lives, the requirements of our employers, the dynamics of the team and the love of coding. The pulling creates conflict and everything breaks when pulled too far in too many directions.

This leads me to my final comment: maybe we can just work for someone else. If the job sucks and our lives are miserable, we can just work for someone else and maybe find that one great job that is more aligned with the way we want to live.

Back

I disappeared around June for a number of reasons and some were great. My son was born and my free time disappeared pretty fast. I am not complaining at all either. My wife and I are always amazed by how wonderful we find him. Blogs take a sideline to one’s children every time.

Another occurred a couple weeks later when I switched jobs. That was a dumb move on my part. Dumb doesn’t really describe what a bad move that was. New jobs have a certain level of stress in general. Being sleep deprived and having to function well with people who don’t know you is a real test. Writing code that works is somewhat more striking.

I spent the past six months writing an application using JBoss’s Seam. That’s a bundle of JSF, Richfaces, Hibernate, EJB 3 and some custom Seam components together. I have this belief that JSF is not the road to web application victory and there will be a post where I try not to rant about it. I have the feeling we will look back at JSF and JSF -based frameworks in the same way we look at EJB 2.0: negatively.

I’ve also been reflecting on the current market and the recession. I’ve looked back at “Being a Developer During a Recession” at regular intervals and want to write so much more. Being laid-off back then was really a difficult time and I was single. I couldn’t imagine what it would be like now with a wife and son. My heart goes out to all the laid off folk right now.

There is a lot of code to write about too. Seam is rich with strange stuff, weird behaviors and traps like nothing I have every encountered. I had this Seam or Safari bug where rerendering a section of a page that contains links with more than one parameter would cause the ampersand character to be converted into its escape character. I ended up have to use javascript method to invoke those urls. I have had to write lots of workarounds.

Lots of architectural things to talk about. Documenting and conveying concepts is a huge one. Key aspects to successfully communicating your ideas to a team. How to listen to your team and accept feedback and incorporate it into your design. That last one has a couple of stories that you just wouldn’t think would happen and yet they did. I’m still surprised at some of the things.

So I’m back at last and I plan on writing a lot.