Code

So Now I'm a Contractor / 16 Tips for Being a Contract Programmer

David J. Sokol — Mon, 19 Nov 2007 07:23:44 GMT

Skip my personal experience and go right to the list.

I realized, last week, that I am a contract coder. I never intended to be one; I wanted a job with a regular boss and a 401k and a health insurance plan. Sure, contractors earn more, but they also deal with a lot more instability in their daily lives. As of right now, I'm not sure if I'll be employed next week. I have a job lined up, but it's only a temp deal for around $1500 total. That covers about a month of my living, if I stretch it thin.

Right now I have a desk and a job and an employer. My employer doesn't seem to exist sometimes; I have very spotty (once-twice a week) contact with my boss, and I deal mainly with the customer over the phone. My paychecks are irregular; I work 40ish hours a week and get my pay at intervals ranging from 6 to 42 days. Right now my paycheck for the 1st was received on the 16th. Over the past few months I've accrued over $600 in late fees due to instable pay. This has all been on the same job with the same contract. Well, contract is a funny word; I didn't sign anything. Right now I go to work and do some stuff and then get paid an agreed-upon amount. If myself or my employer ducks out at anytime, I've got no legal reprisal. I doubt I'll even get 1099ed.

This life sucks. Sure, my friends are making around $7-10/hour, and I'm getting ~$30, but I lose tons of my money to extras. I have to buy my own computers, my own IDE (and add-ons), I have no automatic tax withdrawal, I have to get health insurance through a third expensive party. I'm not guaranteed pay at all. This is, by far, the worst possible career choice right out of college. If I was at a startup, that'd be something different. That'd be a common goal with the allure of hitting it big. No, the best thing I have to look forward to is a slightly bigger paycheck that might on time and not getting nailed by the IRS.

I repeat: do not start contracting for yourself right out of college. Unless you like the adventure and the unknowns or you just have a lot of extra money lying around (Like, taking out loans instead of paying them back, like I start next month), I would not recommend it at all. If you do it on the side to get some extra cash? That's fine; that's extra. But when you first get on the scene and are trying to make some money to eat more then hot-pockets and beer, get a stable job.

If you decide to ignore my above advice, I have some other, possibly more helpful advice that I've learned (and wished I'd followed) as a contractor. I've only been doing this about half a year, but I think it's worth it's salt. It's born out of sweat and tears (well, not tears, but a nervous breakdown or two. Well, the salt that would have been in the metaphorical tears, so lets go back to tears).

Enough with the intro shit, lets get right to it*.

Get your taxes done professionally. There is a ton of stuff you (and I) don't know about that you can get money back on. Well worth it.
Sign contracts with your employers. Starting out it's easy to use the line "Oh, sure, I'll write up that program for $15/hour." Don't do it. Nothing sucks more then bugging somebody for money when you don't have a written agreement.
Don't write code without signed specifications. Write your specifications jointly with your clients and agree what the program will and will not do. Software Requirements from Microsoft Press is a great book, and a must read for any independent contractor. Even if it's a simple list of 'This software will/this software won't', it's better then nothing.
Make sure your employers give you the right tax forms. In GA, if you do over $700 of business with somebody, they need to send you form 1099. This may be a bigger issue with some people, but I find it pretty important. I don't like living in fear of huge fines.
Understand how software licensing works. When I first got out of school, I had my wonderful MSDNAA academic licenses of Visual Studio, SQL Server, Visio, Windows Server, Access... well... every Microsoft product but Office. Pretty much everything you do now will be under the 'unacceptable' category. There's probably a few good resources on the web, but actually going through and reading the EULA before clicking Next does wonders too.
Don't spend money until you actually have it. If you send out an invoice for $1000, don't spend the money until it's back in your hands or in your bank account. Don't assume all clients will pay prompt; calling them on the phone and telling them how you have to pay rent is remarkably unprofessional.
Know when to say 'no' to new features and additional work. Most customers do this unintentionally, but think critically about every little 'change' made to the software. Even something as trivial sounding as upper-casing everything in the application can turn into a hassle; make sure they know it's billable.
Keep track of your miles. Start writing down all of your odometer readings when you drive to and from customer sites. This is tax deductible/See #1.
Track your finances and save all of your receipts. For everything. Get a filing cabinet. Get some financial software. I use MS Money (it's... decent.) Another guy I know uses Quicken. Apparently they both kind of suck, but you need to keep track of everything. Hell, use ledger paper if you have to.
If possible, use a separate email address for work purposes. This makes categorizing everything when it sinks into your inbox. Don't get client emails intermixed with forwards of forwards from relatives who just got the Internet.
Keep business and friendship as separate as possible. When you start out, chances are a lot of your customers will be friends, or friends of friends. Remember, this is a business and your livelihood. If they can't make pay that's acceptable to you (or want something for a ridiculously low price), don't do. Friendship be damned, you have to eat.
Know when a project is too big. Don't agree to do something unless you're sure you can do it. Right out of college, everything seemed easy to me. I estimated a 6 month job at about 1 month. Whoops. Chances are, when you agree to do a small website for a local business over lunch one day, you're biting off a huge project. The line 'I'll have to know about the project more in depth before I commit to anything.' has served me well.
Make sure you have some sort of health insurance. Car problems suck, health problems suck more. One ambulance ride can set you back a few thousand. Nothing will cut your profits faster then a trip to the hospital. It is well worth the $100-$200/month. (Monthly rates may vary, mine are much higher. Damn accident-prone-ness.)
Never ever ever ever ever stop learning. I know this goes for programmers and IT guys and computer people double, but it goes quadruple for the self-employed. Not only do you have to keep up with technology, but you have to keep up with running your own business and everything about your life. You have no handy HR rep to go to. Always be on the lookout for information.
Keep your clients costs in mind. All of the clients I've worked with are fond of fixed-price contracts. Fixed price contracts are hell on developers. We like hourly, in case unknown stuff pops up or your client keeps making changes over time. If your client has a set budget, keep it in mind. Bill hourly, but only work hours that will meet your clients budget. If they have $2000 to spend on the program, and you bill at $10/hour, work 200 hours. Cut the extra stuff, like input validation, and any other crap that doesn't fall into the primary use cases. Yes, there is a matter of personal pride, but presenting a large bill to your customer with excellent software is probably worse then presenting the expected bill with some average software.
Make sure to discuss long term client support options. You might not be contracting forever; who is going to take care of the application after you move off across the country? Not saying that anything needs to be decided, just make sure that all parties know how support is going to work.

* Bonus points for identifying the quote.

Edit: A few days later, some guy on reddit posts this: 10 Absolute "No's!" for Freelancers

. Poor apostrophe-ing aside, it's a good read.

Magic Usually Falls Short

David J. Sokol — Wed, 05 Sep 2007 04:15:08 GMT

Last Thursday I was given the okay to write a company bug tracker. It was pretty clear that we needed a tracker, but I never got the okay to do it. I've been playing with the idea of using SubSonic, but my other project is sitting at 85% completion and I didn't want to introduce new technology until it was delivered. Now was the perfect opportunity to use a rapid development tool to build a new bug tracker. As of today, it's functional. Users can file bugs, read bugs, upload files, assign bugs, etc. All in the span of about 14 hours of development.

SubSonic accounts for a lot of the speed in development. Since I wasn't worried about SQL or SPROCs or database side stuff, I could focus solely on the business logic and HTML. (I must admit that about two hours were spent tweaking stylesheets; I'm a horrid designer.) The project got up fast and I only used the generate command of SubSonic. No Scaffolds or ManyMany lists or Sugar module. To be honest, I didn't deal with the scaffolds until the last hour. I was simply amazed by what they could accomplish in such little code. I had been writing the CRUD pages for my tables, but after I learned of this super-easy method and how well it worked, I deleted my pages and replace them all with Scaffolds.

Huge mistake. (Like, revert huge.) One of the pages I was deleting was one for editing a basic Users table. You know, name, email, address, social security number; the usual. The scaffold worked beautifully for everything in the database. The problem was that the DB table was synced with the ASP.NET SqlMembershipProvider to do security. Whenever a user is added to the system, they get added to the aspnet_Users table by calling Membership.CreateUser(user, password). Right after that, a row is created in the SiteUser table that stores all of the extra user information that we need. They are joined on the user's username. The scaffold doesn't know this, nor does it care. I was screwed.

By using the scaffold in this situation, I was eliminating some necessary behavior in my application. Sure I dropped the code size by more then 150 lines. But the new stuff didn't include the one line I really needed. Whenever you use RAD tools, you usually lose the ability to fine tune.

The same holds true for using a DataGrid vs. a Repeater. The DataGrid does a lot of things magically. I was amazed that it could just auto-generate columns and throw the entire table up onto the web page. After the initial "whooosh" of the magic hitting my eyes at 80mph, I realized that the table wasn't easily customized and wasn't that flexible. I ended up using <asp:TemplateColumn/> for almost every column. Since I was essentially the code inside each table cell, the only thing I gained was not having to deal with the <tr><td> elements. This is still an advantage, kind of. But having all of my data was buried under <td>s and <div>s, it was incredibly hard to style via CSS. I lost a an hour just trying to figure out how to make the <td> elements have a border.

I know it's naive to expect a new tool or technology to magically fix your problems. No silver bullets and all that jazz. When C# and Java came out, it was fantastic because we no longer had to deal with memory management. I think this is a good thing; programmers shouldn't be messing around with memory. With things like Rails and certain aspects of SubSonic, it prevents the programmers from overriding certain methods and styles. When you move up the ladder of abstraction, make sure you don't abstract away control you might need. If you do, you will only solve some problems to create new ones.

10 September 2007: Grammar and style edits.

Developing on Windows Vista

David J. Sokol — Mon, 23 Jul 2007 03:02:20 GMT

Developing on Vista can be annoying. Mostly because of the security enhancements and compatibility issues. Well, only because of the security enhancements and compatibility issues. I, personally, am used to running around on my development machine with full administrator privileges dropping database tables and debugging on IIS. Sadly, in Vista, this isn't possible. Even installing the standard development tools is annoying and requires special steps and patches. A few months ago, I set up a development machine at my house. It took about a day, plus more troubleshooting time. I was about to uninstall Vista entirely, but that would have been the waste of a day.

I recently got a new laptop, a Dell D630, dedicated solely to code/other. It came with a Vista license, and I stuck with it. This is my experience.

The Timeline

2:19PM - Put in the install disks. I'll skip the non-developer related steps.
2:38PM - Vista installed, started installing patches (23 updates) and missing device drivers.
3:18PM - Started installing helper programs, such as Switcher, WinRAR, and setting up WMP11.
3:29PM - Installed the core development utilities: TortoiseSVN, gVim, FireFox, FireBug, IE Developer Toolbar, changing folder options to show hidden files & extensions.
3:48PM - Received "A device attached to the system is not functioning." error. Restarted. Was pretty sure my install was already hosed.
3:58PM - Started installing Visual Studio.NET.
4:17PM - Started downloading Visual Studio 2005.NET Service Pack 1. Averaged 320kbps.
4:43PM - Started installing VS.NET Service Pack 1.
4:57PM - Finished inspecting configuration, actually gave me the prompt to install Service Pack 1.
5:14PM - Received "Error: 1331. Failed to correctly copy MFC80UD.dll file: CRC error." Twice. Doesn't seem to have caused a problem. 2nd error so far.
5:20PM - Downloaded and installed the Visual Studio Service Pack 1 Update for Windows Vista.
5:29PM - Started SQL Server Management Studio Express install.
5:36PM - Realized I didn't have my Office and Visio CDs readily available. Started tearing apart my room.
5:40PM - Started installing Office 2007.
5:49PM - Setup error, had to roll back the office 2007 install. 3rd error. A cryptic one at that.
5:54PM - Started Visio Install.
6:19PM - Initial checkout of the current code-base. (Delayed, I got distracted by Internet :( )
6:23PM - Started Visual Studio.NET
6:26PM - Realized I needed the ASP.NET AJAX extensions installed. Made it happen.
6:32PM - DEVELOP ON!

4 hours 13 minutes. Half a day and a smoke break.

Tips and Common Problems

Run the Visual Studio.NET installer as Administrator.
Run the Service Pack 1 installer as Administrator.
Run the Service Pack 1 Update for Vista as Administrator.
Run the SQL Server Management Studio Express installer as Administrator.
Whenever you run Visual Studio.NET, run it as administrator. If not, things fail in odd ways. Mainly related to IIS debugging.
Whenever you run SSMSE, run it as administrator. If not, you won't have god rights to the database. (This might be desirable, you can just set up mixed-mode authentication and connect with that. I'm lazy.)
If you're having trouble with Internet Information Services 7, read this post.
Yeah, pretty much run anything that deals with memory as Administrator. It gets annoying, but necessary. It's better then having applications silently fail.

Overall Experience

Once you know the exact steps you need to do for Vista development, it's not all that bad. Yes, you have to install a lot of applications, but it's pretty quick. I think a much faster machine helped. (I was using a 5 year old HP ZE5300.) The most annoying thing, by far, is UAC. It pops up constantly. It blacks out my screen whenever I need to start Visual Studio. And whenever I start SSMSE. And I can't directly open .sln or .proj files anymore. But damnit, I'm running this OS as Microsoft intended, though I think it's going to end up pissing me off. UAC problems aside, I've done 16 hours of development on Vista with no other major setbacks. Just don't mess with the Program Files folder with your app or through explorer.

But wait, you're only doing Windows Development!

This is very true. If I used Eclipse, or Java, or Ruby, or Python, or some god-awful Lisp descendent, I wouldn't do it. There are too many potential problems. Vista ain't `zactly shiny. If you're using a desktop, don't bother. Most of the benefits of Vista (that I appreciate) are based on notebooks, tablets, and networking. Otherwise, stick with XP (or OSX or whatever the hell Linux Distro is hot.) If it comes prepacked with a new PC, I wouldn't recommend reverting. You're gonna hafta get with with the future at some point. Or you could just run Windows 2000 for two years after XP's release, like I did.

Learning to Estimate Development Time

David J. Sokol — Tue, 12 Jun 2007 02:43:31 GMT

When you're taking a class in computer science, the schedule is fixed. The semester will be over on this date, end of story. Your project will be due before the end of the semester. Individual projects may be pushed back, but that's a rare case. This is somewhat similar to what I'm seeing in professional programming. Your project will be done by this date. The difference is how the dates get set.

In class, professors set due dates for assignments. Of all my courses, not a single professor has come in and said "Okay, you need to program a R/B tree. When do you think you'll have it done?" I guess I always thought that I'd be given target dates to work towards. Until I moved into management, anyway. Actual programming in the real world has taught me differently. My boss is constantly asking me for schedule updates. "When do you think you'll have component x done? What about component y? Can you ditch feature j and finish feature i for the demo next Tuesday?" I've never estimated my own dates, ever. And I must say, I'm pretty horrible at it.

I've missed every single estimate so far. At minimum by three days. And I'm not even working in an extended timeframe, I'm doing three week estimates max. Thankfully, the books I've been reading (mostly McConnell and general-development MS Press books) have all stated the same thing: software estimation ability gets better with practice. So I don't feel too bad about it. I've been making a bunch of neophyte mistakes. I'm still excited about the project, and I haven't been tripling my estimates. Learning through practice, and all that jazz.

But experience alone isn't fast enough. I needed to take action! What I have done is to make a table of whenever create/commit to an estimate. If I say I'm going to have component y by day 15, I write that down. Then I record how long it took me to finish component y. Sadly, only one of my components is actually complete; I need to start estimating in less broad terms. Here's a look:

Task	Estimate	Actual	Comment
Data Access Objects	10 days	16 days	Underestimated data model complexity.
Contract Component	7 days	:(
Claim Component	7 days	:(
Finance Component	10 days	:( 2x
Graphical Prettying	5 days	:\|
QA Phase I	5 days	:(

The smiley faces are optional. I find them cute and humanizing.

Keeping track of your estimates gives you data to look back on, to make your future estimates better. My scheme fits nicely into an excel or *erk* Google Spreadsheet. Whenever my boss comes into my office and asks me when a component will be done, I just fire up excel and add a row. A quick easy way to record your estimate history. Since I'm doing it using a simple spreadsheet without using a super-complicated CASE tools, it might even be considered Agile. I'll see how it works out. I think by the end I'll end up being off by a factor of two in most components. Especially considering my soft (self set) deadline for project feature-completion was last Friday. Here's to hoping to more accuracy in the future.

Dev Log - Week 04 Day 01

David J. Sokol — Wed, 30 May 2007 04:58:18 GMT

My programming is in full getting it done swing. Comments are being neglected, horrible things are being done with try {} catch {} blocks, and variable names are becoming less useful. Writing high quality code on a schedule is harder then I originally estimated. A lot of my scheduling problems are tied to my work environment. Well, the part of my work environment: my paycheck. Essentially, I don't get paid until I finish the application. And my paycheck is dependent on delivering a working program; not a maintainable one.

I guess it's the plight of most software developers. Debates about languages and closures and whatever the hell else is good for academia, but it really gets in the way of getting things done. I'm not an academic, but I believe in good code. It's a tradeoff. Do I spend a few extra minutes here commenting code? Do I write down my thought process and reasoning for a tricky bit of functionality when my power bill is going unpaid? What exactly is my motivation to write good code when my paycheck is the same? I certainly won't be maintaining this code; I'm out as of August 2007. It'll be a guaranteed revenue stream (to the tune of $3k/month) for my employer, not me.

Professional dedication can only go so far. As much as I hate it, I go to work developing enterprise applications and come home and dream about developing other applications. Not shrink wrap or games or anything, but just doing development work that's not my job. Yeh, I'm that much of a geek. Point is, I'm supposed to be living the life! I'm a professional developer now! My systems are going to be making an impact on the people who use them; I'm drawing a paycheck for making them awesome! External deadlines and milestone markers really dampen the whole programming experience. As does reality, but that's more philosophical then I'd like at 4:49AM.

Bottom line: my code quality is suffering. I've been developing for this company since March, but I've seen one (yes one) paycheck. There is a large amount of money outstanding. It feels like I'm working for a bootstrapped startup (something I swore I would never do) except I'm not doing anything new and exciting. I'm banging out data access objects and business rules for an insurance underwriter. Dreams of my enterprise career definitely included a steady paycheck, and this just isn't cutting it.

On the plus side, Gin and Tonic is still as tasty as ever.

Dev Log - Week 03 Day 05

David J. Sokol — Sat, 26 May 2007 04:58:18 GMT

The past few days have been horribly boring, development wise. New project excitement has faded; new technology excitement has been benched. I’m just sitting behind the keyboard and and making it happen. Bread and butter time, and my morale is soaring. Boring repetitive work is the enemy of the automation programmer.

I’ve been doing all of my development without the aid of outside 3rd party software, such as NHibernate, NUnit, or whatever other plug-ins you can Google for. All of the SPROCs, database maintenance, testing, and other tasks are done by hand. The primary reason is future maintainability. My term at the company comes to an end in early August; other programmers are going to be stuck managing my handiwork. I don’t want to drop new programs on them as well as new code.

Programming without basic automation utilities is rough. I spent a few hours today writing SELECT/INSERT procedures for the database, one at a time. I’m at twenty-seven tables and rising; the numbers are killing me. Not to mention what happens when I need to make a database change. Despite my massive one week planning period, there are still data model changes to be made. It’s annoying. If I add a single column, I end up changing code in four places: two in SQL Server Management Studio, and two in the C# Data Access Object. And then any calls I’ve made to the INSERT or UPDATE functions. It’s a total timewaster, compounded by the fact that I only compile/run when absolutely necessary.

Ah, absolute necessity. My development machine is a 2.4ghz P4 with 768MB DDR. It’s a laptop, complete with 5400RPM drive. Once I get the basics up and running (Visual Studio 2005.NET, SQL Server Management Studio Express & related instance, explorer, iexplorer x 2, and WMP11) I’m out of RAM. It takes more than thirty seconds after hitting F5 (Run with Debugging Enabled) for the browser to load. It truly is development hell. Thankfully, I’ve learned not to hit CTRL+SHIFT+B (Build Solution) every few lines.

Having such a crap machine limits my multitasking. If I work in Visual Studio for more than a few minutes, SSMSE gets paged to disk. If a database change is necessary, I’m looking at two or three minutes wasted just waiting for programs to page back and forth. It’s maddening. There are points where my processor is so laden GMail won’t stay connected. Not being able to automate the boring stuff and doing it by hand blows hardcore. If I ever start ~~developing professionally~~ start a development company, every workstation is going to be riced out, save video card. I just can’t stand working on a machine where I can type faster than Intellisense.

It’s just been boring, repetitive, slow work. Thankfully, I’m probably going to finish up most (ha!) of the boring parts this weekend. Come Monday, I’ll be working in new exciting territory again. No wonder people get all excited about Haskell and Ruby and whatever other language of the month is. Anything that auto-magics this tedious part of programming is worth raving about, no matter what constraints are put on style/syntax/format.

Dev Log - Week 03 Day 02

David J. Sokol — Thu, 24 May 2007 04:58:18 GMT

Development time was short today due to a migraine. Missing a few hours (say, six) really reduces the amount of work you can get done. That being said, I sat in front of the TV with my laptop in the evening and tried to catch up.

After yesterdays near disaster, I decided to switch into XHTML mode and work on user controls. I created a few user controls in my prototype, and I was planning on translating them into production code. The particular component I’m working on is a modified DataGrid. It contains one or two extra search boxes and some custom pagers. Now, when I say custom pagers, I don’t mean the Custom Pagers that the DataGrid natively supports. These are full-on DataGrid-unaware pagers that I’ve written ground up. Some background is in order.

Most of the projects our company works on are business intelligence applications; we grab tons of data from the database, run some reports and calculations on it, and present it in an executive dashboard. The DataGrid pagers don’t actually paginate the data itself; just the display of the data. We page our data because NOT paging it would cause a few thousand extra rows of database traffic. Our users tend to prefer short load times to long ones.

The pager I’m writing contains the standard data-pagination buttons: First, Previous, Next, Last, and a number-of-items drop down list. We plan to place these buttons on the top and bottom of every DataGrid contained in our application. This paging bar is going to be used multiple times in the application. The object-oriented designer in me is currently screaming that I package this tiny piece of functionality up into a nice reusable component. Since it’s graphical, a user component (or custom component, for that matter) would be ideal.

However, making it object oriented would add complexity. The events for the links contained within the pager would have to be subscribed too externally. I’d also have to deal with all of the visibility and possible rendering problems caused by the AJAX controls I’m using. And, frankly, I don’t care for the idea of nesting user controls. My gut feeling is that Visual Studio would throw a fit during compilation; I’ve experienced this before, and have lost days of dev time to it.

It’s a sticky design situation. So I decided to program around in for about an hour, tidying up other code, creating the helper classes, and so forth. Right before I had to make the decision, I got up off the couch and walked to my friend’s room. My friend is also a programmer, a recent computer science graduate. He works for a different company on the third floor of the building I work in. Without any context, I posed him a question: Quick! Proper design or getting it done? He turned away from WoW, glanced around nervously, drank some Coke he had sitting on his desk, and, very slowly, replied getting it done. You have to love making software design choices on exchanges like that.

Getting it done was what happened. I started copying and pasting code (screw design error!) and finished up the first component pretty quickly. I can’t estimate how long it would have taken to make it reusable, but c/p was a couple of minutes per occurrence. For me, in this situation, reusable design would have cost more. What’s even nicer is that Visual Studio changed the IDs of the ASP components for me when I copy and pasted, so there would be any ID conflicts. It’s as if Microsoft anticipated my shoddy programming technique.

Now lets see what happens when I have this particular pager code copy and pasted into ten or twelve different places on the project and the customer requests an All button.

Dev Log - Week 03 Day 01

David J. Sokol — Wed, 23 May 2007 04:58:18 GMT

I’m in the middle of the implementation phase of my project. The last week or so was mostly planning out the scope of the application, which ended up being a lot of waiting. Do they want to be able to X in the application? Hmm, not sure, lets ask them. An hour or two later, I’d have my answer and I could move on to the next design question. A few religious debates later (including one where I was arguing against CodingHorror) we were settled on the design and implementation strategy. The application is nothing fancy; a simple insurance underwriter system, Web based, written in ASP.NET 2.0. The biggest cool factor to the whole thing is that we’re using the ASP.NET AJAX extensions. UpdatePanels are pretty rock.

The specification process wasn’t anything special. Whoever wrote Software Requirements from Microsoft Press (which Google later reveled to be Karl E. Weigers), would be appalled. I’ve never met the customer, and my only method of contact is through my manager. Not exactly joint application development. The spec is penned out in pseudo-use-case-UML and stickypadded to the cabinets in my office. We have an ER diagram, but that’s by my own hand alone. I’m essentially developing a program off what’s in my head, a single ERD, and two Self-Stick Easel Pads. Ah, this is my welcome to enterprise development.

Either way, the program is getting written. Today I started slogging through my Data Access Objects now, which ain’t `zactly fun. I like to imagine LINQ. just sitting on my shoulder, taunting it’s super-cool in-lining abilities I can’t use. Over the course of forty plus table attributes, my wrists started hurting. The wonderful advice I’ve received about taking breaks while working is finally making sense. At 2:02PM, I decided it was break time.

After waiting for the Coke machine to timeout on my credit card authorization, I took a walk around the building. You know, just to wring out my fingers and to hope the Coke would work next time I tried. Then it hit me. There was a problem in our software design that would cause the customer to do horrendous amounts of data entry, along the line of 6,600 records. I stopped in the hallway and thought about it for a second. One of the reasons we were developing this software in the first place was to automate this kind of thing. Surely we (read: I, in this case) couldn’t have overlooked this fact? I jogged back to my office, checked the ERD, and went into an instantaneous depression.

Yep, it was flawed. The customer would have to enter 6,600 records (granted, with one column each) upon delivery of our product. My development efforts ceased and all my energy refocused on eliminating this problem. Two hours later, I had nothing to show for it but a lot of failed ideas. Somewhere during that time the someone-just-broke-up-with-me feeling hit. The product wouldn’t work as promised. It wasn't time for the We're Doomed speech yet, but I was planning it. I started discussing it with a co-worker, who had just come back after house-shopping.

Bottom line: it’s the customer’s problem to do data entry, not ours. After an hour long discussion, we decided that the problem was domain specific and, sadly, irresolvable using our techniques. I would continue to develop as plan, and just try not to think about the poor administrative assistant that was going to have to do data entry. The problem was solved, but I was still fairly shook from the ‘oh ***’ moment earlier that day. I typed up a few more methods then headed home. Apparently software can’t solve all of our business problems. Maybe I was just being naïve about it, but I was hoping that this product would really reduce all the tediousness of the customer’s current tasks. It will, but there will be a high initial time investment. Today I learned that design is about compromise.

Adventures Into Unit Testing

David J. Sokol — Tue, 01 May 2007 04:58:18 GMT

The software engineering course at my university covers a lot of material. So much material, actually, that much gets glossed over or exempted. One hour on a Tuesday afternoon we talked about unit testing. Yep, one whole hour to discuss this great, fantastic, oft-blogged about technique. My professor didn't care for unit testing, and didn't see the purpose. His viewpoint was made clear through his rather sarcastic slides and comments. It's a waste of time: If your code runs, you don't need to programmatically test it! Just get it done. I'm paraphrasing a bit here, but there's the gist of it. In his use of the word it, he was referring to our semester long projects. Giant, massive ordeals that were to be completely working, tested, and documented in sixteen weeks; by groups of four or less people. Ours was an amazing adventure, but that's another topic. Needless to say, unit testing was wasn't even attempted on any of our projects.

So, despite my Computer Science degree, I have no real training on unit testing. During my software engineering class, I decided to do some outside research. I downloaded NUnit and gave it a shot. Wow! It was cool! All that green lighting up everywhere, boosting my confidence in my 500-600 line projects. Despite it's crazysexycool appeal, I quickly determined that it was unnecessary. Throwaway code for grades doesn't need unit testing, no matter how you slice it. I tried introducing it into another group project I was working on later and almost suffered a programmer revolt. Unit testing apparently has no appeal for academia. Then again, most programming for classes is built on pizza and beer fueled 48-hour no-source-control code-a-thons.

Now I'm at a real job. Well, not exactly real, but real enough. I'm re-writing a superhuge, ~~43,000~~ 59,766 line PHP application. (Shut it, I'm new to this.) After two weeks of deciphering both poor naming conventions and rampant use of REGISTER_GLOBALS, I was finally ready to start writing code. One week after the initial repository creation, I realized I hadn't even touched the run button in Visual Studio. This was somewhat alarming; I had 1500 lines of untested C# and 2000 lines of slightly-tested SQL, just staring at me from version control. It compiled, sure, but I've learned that doesn't mean much. Ignoring my insecurities, I continued writing code for the rest of the week. Insecurities don't go away though, they just build. The following week, I couldn't take it anymore. The longer I wrote code without checking it, the larger a chance of a major design flaw appearing later. My work had to be validated. I re-downloaded NUnit (The prior copy being gone, oh, 4 OS installs ago), added some assembly references, and began writing tests.

Unit testing a project that wasn't meant for unit tests causes problems. Google found some best practices and started re-writing my base code. Hours of refactoring later, I had about 10 working unit tests. My code had actually worked pretty well the first time around. I was (and still am) pleased with myself. From that point I decided to use the Test Driven Development (TDD) methodology. Stub your code out, write the tests, watch them fail, then fill in the code and watch them pass. Thirty public void SomeTest()s later, I gave that up. Wait, what? Yes, I gave it up.

I work for a small company that does contract programming. I found, through measuring the time it took me to write classes of comparable complexity, unit testing was doubling to tripling the time it took me to write code. So what!? you cry. You'll get better code in the end, with less time debugging and more confidence! Yep, understandable. Right now, though, I live check to check. If I don't get this code into production, my power bill goes unpaid. I'm willing to take the risk of finding more bugs in the QA stage (which is conducted by the company) by saving time now. Following all the other good development practices should be enough to keep my bug count down, but unit testing just isn't worth the time investment. This is a single company website, custom tailored to their needs. Chances are the only people that will ever see the code are my co-workers.

The fundamental concept of unit testing is sound. I think, given the right time and training, it would greatly improve anyone's code quality. Sometimes that extra quality just isn't necessary. I'll liken this to food, since most people eat. Unit Testing should be used when you want top of the line food, say, Heinz Ketchup. However, if you just need to get the job done (e.g., making something taste like ketchup), get the Great Value brand. Great Value ketchup makes things taste better, but it's not as high quality. Unit testing is the Heinz quality control process. If you have the time or the desire for high quality, use it. If you have a deadline and you can get away with a few bugs, don't bother. Your time is better spent adding new features. Business customers like features, and they're mainly focused on getting the job done.

Note: Don't bother saying Great Value is just some repackaged brand. I'm aware. Just use the damn analogy.

Update 01 May 2007: Fixed linecount due to brand-spankin-new find | cat | wc knowledge.

Yay! More/Less Student Competition!

David J. Sokol — Sat, 28 Apr 2007 04:58:18 GMT

Computer science enrollments at my liberal-arts university are up. It had been dropping recently, but a few new faculty members and some higher profile advertising changed that. The CS department usually grabs people who are drop outs from the GaTech Regional Engineering Program (GTREP) or students from other majors who require a computer course. The department is still growing very slowly; I'd estimate 2-5% growth on a program that graduates about 20 people per year. That's not being echoed by other Universities. Computer science enrollments are down, despite efforts to boost them. According to an article I read in Network World (which I cannot find online, but it was the last-page editorial column), the total amount of computer scientists enrolled is about to drop. I disagree, but I have to explain my perception of the dot com era first.

Dot com started in 1996. The internet held huge amounts of untapped wealth, just waiting to be grabbed by the next geek with a P2 250Mhz and a weekend supply of Diet Shasta. Computer science enrollments exploded, along with the web. The stock crashed in 2001. Those students who enrolled in university during the height of the bubble (from 1999 to 2000) stuck with it, finished out their program, and went into the industry a few years ago. The students that followed behind it, who were in high school at the time, are graduating now. Soon the students who were choosing their major as the major financial backlash hit the technology community will be graduating. Most of the people in my classes have no fear of not being able to find a job, regardless of outsourcing. Current graduating CS students love computers enough that the .com burst didn't scare them away. These are the dedicated programmers; screw financial problems, screw india, screw liberal arts. And they're all going straight into web development.

These the-bubble-didn't-scare-me programmers are the ones behind Web 2.0. They take risks that older seasoned programmers won't. They never experienced the harsh realities of losing their job or being unable to find work. (Note: I graduate college in two weeks.) They do, however, remember the stories of internet millionaires, and they're thinking they can be one. With all of this new Web technology, it's certainly possible. The mistakes made in 2000 are going to be repeated because the Web 2.0 crowd wasn't around to benefit from them. It's kind of hard to care about the state of the industry when you're sitting in Data Structures learning about linked lists.

Jeff Atwood thinks we're in another bubble. I agree, to an extent. It's going to burst sooner or later, heralded by a sharp drop in Google's stock price. Then the entire economic situation will repeat itself. It's just not going to be as bad, because it's only being perpetrated by the industry neophytes. The people who have been programming for the past five to thirty-five years will keep the industry on target, but it'll involve some wrangling. Right now, the web is hot hot hot: look at Facebook and MySpace. People are turning down huge sums of money for their startups because they want more. If cash keeps flowing into the Web, more people are going to enroll in CS courses (yeah, pretty basic logic, I know). The next few years should have a huge increase in computer sciences enrollment. Then current market will crash, there'll be devaluation, then in another few years, Web 3.0 will come from the kids entering the CS a few years from now. Every industry cycles to some extent, the IT sector just does it faster. Same thing happens to university computer science enrollment. A few years of more CS students, a few years of dropping numbers.