Where I've hung my hat this last year

For the last year I’ve worked as the Director of New Media and Web Development for 614 Media Group. It’s a lofty title, meant to inspire all who read my email signature that, “Hey this guy is a bigshot.” In reality what I did was much more mundane, I wrote LAMP applications. For the last year I’ve sat down everyday at this Mac, popped into TextMate, and wrote PHP. I was king of the castle, and being king is good, I got to choose my tools: Mac + TextMate + Git + MAMP + MacGDBp + GitHub + GitHub Issues + Flourish. I got to work on interesting products, if you had told me a year ago that in a year’s time I would have written both a Groupon Competitor and a full CMS system, I would have told you that was crazy talk.

Over the last year I have grown as a developer and as a system administrator and as someone trying to get traction for a new product and as a million other hats I got to wear. For the first time in my career I was able to go from concept to “functioning-putting-money-in-the-bank” web application. This is huge. Having been a consultant for years before this job, I spent most of my time maintaining other peoples systems, throwing in a feature here or there, coding up a new report, stuff like that. At 614 I was able to start from nothing, build up a database schema, create the framework and the code, paint it all pretty, launch, iterate, relaunch, iterate, tear my hair out, wake up to fix problems at 3am, curse the server for being slightly different than development, drink more caffeine than any human should drink, but most importantly learn and grow.

With learning and growing in mind, I have an announcement to make, at the end of this month I will be leaving my job at 614 Media Group. I leave on a good note though, the software is stable and quietly humming along bringing in revenue. I am leaving behind a framework with a proven track record, a stable foundation that can be built upon. But most importantly I’m leaving as a friend and supporter of 614, wishing them nothing but the best for the future. 614′s curse is that they put a lot of responsibility into your hands and if you are good at it, other people will take notice, and those other people may come in and make you an offer you can’t refuse.

They made me an offer I couldn't refuse

I’m not sure how much I’m allowed to say about the new position, but I will be moving out to the West Coast this month to start a new chapter in my career. For the PHP folks out there, do not worry, I will still be rocking PHP (but also probably rocking some ruby and java as well and anything else they want me to learn). This is a big, stressful, somewhat scary decision to make, but I believe in the company that I will be joining, and after meeting with their people am nothing but excited to work with and learn from them.

Growth and change are good things, they can be painful and stressful and sad sometimes, but the minute you stop growing as a developer you’ve given up, and I love programming too much to give up. This next month is going to be a blur of packing and moving and unpacking and learning a new area and learning a new codebase and new people and new places. Parts of it will be uncomfortable, parts will be stressful, but overall it will be a learning experience I couldn’t get anywhere else, and I wouldn’t have it any other way.

You got Spreadsheet in my Web App, you got Web App in my Spreadsheet... and it's delicious!

Note: I may seem a bit harsh on Excel, but I actually think it’s an amazing piece of technology, I just don’t like how people abuse it.

Web development for business people follows a fairly predictable path. Here is a generalized form of it.

1. Business person encounters problem
2. Grabs Excel, Excel being the magic fix for everything
3. Creates abomination of a solution in Excel, it grows too large, concurrency and consistency issues creep in
4. At this point normally a web developer will be brought in to “Make this Excel sheet work on the internets”
5. Work work work work work…
6. Everyone is delighted
7. Hey is there anyway we can dump these value back into Excel?!
8. At some point they will use the dump to create some new spreadsheet, go back to step 3.

Now of course it’s not always this bad and normally there are really good reasons to dump things back into Excel, instead of bothering the web developer with a bunch of business analysis, they can dump the data and perform the Excel wizardry they love so much. I actually think this is a good idea, instead of me baking in calculated values or reinventing Averages and Means and all the other cool stuff Excel can already do, I just drop them off some nice raw data and let them have their business fun. They get exactly what they need, I get exactly what I want (less fragile code with less crazy business rules) and everyone is happy.

Now in PHP there are various solutions to dumping out Excel. The first would be the venerable Spreadsheet_Excel_Writer. I’ve used it before and it works, it’s a port of a Perl library called Spreadsheet::WriteExcel, but there are a few drawbacks. The first is that it’s a PEAR module, you use PEAR to install it and it brings along all kind of PEAR stuff like PEAR_Exception and the like. The second is that on the homepage for Spreadsheet_Excel_Writer is this very happy message, “Spreadsheet_Excel_Writer is outdated and needs a complete rewrite. If you want to help with this task please get in touch with us. Otherwise we don’t recommend this package for new development.” So in short, we should avoid Spreadsheet_Excel_Writer.

The next thing you might find in your googling is PHPExcel which writes out OpenXML 2007 files. This is another large and much more well maintained library for working with Excel files. If you need any advanced features I would highly suggest looking into this one.

But I want something simpler than this, I just want to dump some data out. I don’t need to have all these bells and whistles. Also I hate the fact that to write out a few cells in most of these Excel Libraries requires the following.

$objPHPExcel = new PHPExcel();
// Add some data
$objPHPExcel->setActiveSheetIndex(0);
$objPHPExcel->getActiveSheet()->SetCellValue('A1', 'Hello');
$objPHPExcel->getActiveSheet()->SetCellValue('B2', 'world!');
$objPHPExcel->getActiveSheet()->SetCellValue('C1', 'Hello');
$objPHPExcel->getActiveSheet()->SetCellValue('D2', 'world!');

The way these libraries work are just, ugh. They are very heavy and when you are just trying to plop some values into a spreadsheet so someone can have at them, they are overkill. I found myself rewriting the same solution again and again, it’s a fancy little solution using some pack() magic that I found over here. Here’s what a simple little spreadsheet looks like.

require_once('Excel.php');
$sheet = new Excel('My Awesome Spreadsheet');
$sheet->label('Hello');   //Write out 'Hello'
$sheet->left();           //Move the cursor left
$sheet->label('World');   //Write out 'World'
$sheet->down();           //Move the cursor down
$sheet->home();           //Head as far left as possible
$sheet->number(1337);     //We are so 1337
$sheet->send();           //Melt the user's face off

This has met my needs and you can find it as a Gist right over here. I wanted an object oriented way to use those functions and I wanted some help in moving the cursor around and some simple sanity checks on things so that I didn’t ruin anything. It’s got plenty of comments in code and should be pretty simple to pick up. You can write out labels or numbers and you can move the cursor all around, left, right, up, down, top, and home (top being the first row, home being the first column).

For right now this is meeting all my needs and more, I’ve recently been playing around with the fact that Excel will happily turn HTML Tables into Spreadsheets, I’ve got a library cooking for this but have been playing around with some interesting ideas for styling and other advanced features. Until then hopefully this will help any PHP programmer who just wants to dump out some data without going into dependency hell.

Happy Coding

Get my handy dandy Excel Writer here

Machines are complicated, so is software

A while back I saw a post in the Flourish discussion boards requesting a Form Generation system, see here. The short discussion that follows basically argues that form generation is too subjective and although it may at some point be added to Flourish it won’t be anytime soon. I work in Flourish all day, everyday, and I love every minute of it. I’m probably beating a dead horse at this point, but Flourish really is just a tremendously solid core to build off of. Working with Flourish so much and finding myself performing the same form mark-up again and again, I’ve given some serious thought to building a Form Generation system and have been using a prototype system for a week or two. Having built a working Form Generation system and used it for a while I want to talk about the good, the bad, and the ugly.

The Good

As a programmer there is nothing more frustrating than finding a library or an API you want to use and having it just be an absolute nightmare to integrate with. I spend a lot of time, ever since Prosper, thinking very hard about how to provide great APIs that make people want to use my software. After a lot of thought about how to go about building a Form Generator library, I’ve come to what I think is the right balance. The ideal API should fit well with the Flourish way of doing things, be flexible, powerful, expressive, and extensible. So without any further bloviating, here is my proposed syntax, in this example I will use a simple sign-in form.

echo fForm::post()
          ->add(fForm::text('Username'))
          ->add(fForm::password('Password'))
          ->add(fForm::submit('Sign In'));

This would produce the following output

<form action="http://the/current/url/" method="post">
  <label for="username">Username</label>
  <input type="text" id="username" name="username" />
  <br>
  <label for="password">Password</label>
  <input type="password" id="password" name="password" />
  <br>
  <input type="submit" id="sign_in" name="sign_in" value="Sign In" />
</form>

The API is fluid, simple, and concise. It follows the Flourish style and uses fGrammar::underscorize() to turn labels into ids. It produces clean simple markup and doesn’t mangle any ids, allowing for JavaScript to be easily attached. As far as the API goes, I’m really quite happy. The other powerful thing this allows you to do is tightly integrate your Form Generation with value repopulation, for automatically refilling in values when an error occurs. With this tight integration I’ve been able to create a prototype system that automatically repopulates across posts when an error occurs, can use an existing fActiveRecord instance as a seed to make editing amazingly easy, and display beautiful inline errors on the form.

The Bad

Having used the prototype for a while I can say it’s not all great. Simple CRUD style forms are incredibly easy to mock up, having error values persist automatically is really nice, and having inline error message (especially those from fActiveRecord::validate()) work with little fuss has been a huge speed boost. I can knock out simple pages in a fraction of the time. The problem comes when I want to do some edge case, PHP’s greatest strength is easily outputting whatever markup you want, by introducing this layer of indirection you give up this inherent strength for whiz-bang features. It’s still incredibly easy to output whatever markup you like, but the disparity between the automatic features the fForm library gives you and your own simple markup is stark and will bewilder a normal user. The problem here isn’t that fForm lacks power, it’s that it imbues certain elements with too many features and makes creating a one off element prohibitively expensive.

The Ugly

The architecture that worked best for implementing the prototype was a tangled mess of inheritance, and no matter how much I tried to refactor I still haven’t found an inheritance graph that I find acceptable. Using my prototype has considerably cut down on development time, but the amount of memory used holding a object graph in memory to represent complex forms is a trade-off. The API has several inconsistencies that bother me, but don’t really impact the performance or usability of the library.

The Future

So where to go from here? That’s the question I keep coming back to. I want to introduce a layer between object graph and view, this way a plugin system can be used to change the rendering of elements and the form itself in a fundamental way. As soon as possible I plan on releasing a clean room open source version of the fForm library for use with Flourish on GitHub. I believe I’ve come up with a way to make an easily extensible widget system, now I just need to get something out the door. I will release it with my alpha framework, Rigby, in the coming weeks. Comments, and of course forks, are welcome. I will release some screencasts about how to use Rigby once I get it into a stable state. Stay Tuned!

Just a little more to the left....

I’ve been working, both on the job and as a freelancer, right now my 9-5 is starting to enter that ever so exciting phase where one project enters maintenance mode and another project starts to spin up. The new project starting to spin up is to rewrite the CMS system that powers our various publication websites. Now for those of you not in the know, a CMS system is crazy complicated. I’m writing this current blogpost in a very specialized CMS system called WordPress, just for blogging. This software probably has had somewhere upwards of eleventy-billion man hours go into it (once you factor in themes and plugins and all that jazz).

Of course whenever you are faced with a complex problem that’s been solved to death your best bet is to look around and see if anyone has done the heavy lifting for you already. So I started looking around, WordPress, Joomla, Drupal, all mature PHP CMS systems, none that I’m familiar with even a little. I started reading, out of the three I ended up liking Drupal the best, it seems well engineered, flexible, and very stable. I read and read and read about nodes and the way Drupal thinks about content and I started to think, ok maybe we can use this. The problem is that management is used to a level a flexibility that I won’t have with Drupal for months, maybe even years. They want this flexibility from the beginning and that was making using Drupal seem less and less likely. Then some requirements filtered in and out and it looks like a custom solution is going to be best… c’est la vie.

Now this is in no way a slight against Drupal or Joomla or any other CMS system out there, I’m sure in the hands of Drupal Ninja or Joomla Gurus this would be easy as pie. For me though, building a solid system on my time tested and well worn toolbox of PHP, SQL, and Flourish will probably be the best way to deal with the constantly changing features and requirements that we need to support. Now I’m going to start building, start sketching out how things will work, how data will be thought of in the system, user models, documents, revisions, all kinds of fun stuff. It’s a bit intimidating, but as a Software Developer this is really the stuff I live for, big gnarly problem, blank TextMate buffer, well known tools, get cracking.

The big problem I’m fighting right now is the dreaded Second-system effect. Watch out for this my dear friends, it’s not a nice trap to get caught in. It works a little something like this.

1. Build a system, this is the First-system, it works, celebrate and have a shot of Jack.
2. That stupid “real world” comes in and messes up your data model, you add a little hack to compensate.
3. Oh, it has to be able to do what? No, you said it didn’t have to do that!! Fine, hack hack hack.
4. Maybe some cleanup, probably some more hacking and bending.
5. You’ve tried your best to keep First-system shiny and new, but the shine’s off the apple.
6. Crazy requirement, requires rewriting huge parts of the system, oh noes!
7. Alright, now that we know so much more let’s build Second-system.

Herein lies the danger. You get the go ahead to build Second-system, and you have all this experience from First-system, you really think you understand the problem domain a lot better, so far so good. Here’s where things get hairy though, you start thinking about how you would build the system so that you don’t run into the same problem First-system had, you start abstracting and abstracting, it gets more and more complicated, but you are now a master in this domain, you can handle it. Users who have been frustrated for months or years using First-system start throwing in their advice, things that have always bugged them, their nice-to-haves, and hell, you haven’t built anything yet, chuck that automated-frog-boiler in your system plan.

Before you know it you’ve got a beautiful masterpiece, it handles everything, all the problems encountered in the First-system, all the nice-to-haves, everything, it is a theoretical thing of beauty. Now all you need is 6 maybe 7 years to build it…. oh shit. But there’s something even more wrong about the Second-system, it has buried in it a dirty lie, that you understand the problem domain. You probably have a pretty good understanding of the problem domain, as it stands right now. Having already tackled this problem once does not make you clairvoyant, there will be changes to the system and your system will have to adapt to those new realities. This compounds the Second-system effect, because your Second-system is almost inevitably more complicated than the First-system and therefore harder to change and bend and make work in that pesky “real-world.”

Right now I have to fight the urge to over-engineer, to outwit this problem, because I’m just not smart enough to solve this problem forever and ever into the future. So I’m going to focus on building a solid platform that let’s me build out modules and snap them off when they aren’t needed anymore. Something robust but simpler than the current system. Doing this will mean trading things off, it will mean making hard decisions upfront about architecture to meet our current needs but also look to the future, and this is what a good Software Developer is supposed to do. And once my current project is safely resting in maintenance mode, quietly humming along making my company money, I will begin building a Second-system and hopefully avoid Second-system effect.

nerd law also required I use a picture with Spock in it

As required by nerd law, here is my mandatory post on the iPad. I’ve got lots of nerd friend and the general feeling I get from them is a sigh and a “meh.” The term “underwhelmed” is being thrown around a lot, reinvigorating the debate as to whether or not there is a perfect amount of “whelmed” one can be so as to be neither under- nor over- whelmed. Here is my take on the new shiny.

Let’s not forget our history. When the iPhone came out people far and wide declared that it will fail, is failing, already failed. Yet despite such serious problems as no cut-and-paste and a weird virtual keyboard, somehow it won Time’s gadget of the year award, and a huge population of happy iPhone users. People to this day don’t quite get it, I have an Android phone (one of the first G1s) and I love it, but there is no denying the sexiness and sleekness of an iPhone. If you don’t understand the big deal play with one for a week, its just a completely polished user experience.

That is the strength of Apple’s products, the experience. Its easy to find plenty of small, reliable mp3 players that store tons of music, people buy iPods because they are seamless and easy. I was asked recently what made OSX superior to Win7, I didn’t have an answer, I work with both and I enjoy OSX much more but have no real good bullet point for why. I was looking for some big reason, oh the dock, oh it’s pretty, oh the finder, but couldn’t think of any quantitative reason why they were better. When it came down to it, there are just a million little reasons that all add up to a great experience.

To each their own though, I don’t want to start a Windows vs. Mac flamewar, there are plenty out there if you feel the need just type “I hate Windows” or “I hate Mac” into google if you must. The point I want to make is that Apple thinks about their products from a full end-to-end experience, and that’s where something like an iPad could beat the pants off of a netbook. Make no mistake about this either, that is where they are targeting, Jobs said it in the keynote and the pricepoint confirms it. iPad is not meant to compete with MacBooks or Dell D830s (the computer I’m currently typing on) they are meant to compete with Dell Inspiron Minis and eee PCs

There is a niche market out there and I think Apple has the marketing and business savvy necessary to corner it. With all the hype it would have been difficult to not be underwhelmed. It doesn’t cure cancer or come with a free pony, boohoo!

Now I’m going to take my life into my own hands here and make a prediction (watch out!) The iPad will succeed, it will have a spreading pattern to certain niches until it picks up a critical mass and people who don’t really need them start to buy them. First the early-adopter and mac-fanboys will start buying them up, then there will be some app that endears it to some group of people in a fierce way. Maybe a text-book app or medical records app, whatever it is there will be some population that is in love with the iPad. They will start to infect their friends and family with iPad fever and it will become hip and cool, then it will become annoying, and then it will just be fact, 30 jillion people have iPads and you won’t be able to walk into a Starbucks without someone reading Hipster monthly on one.

I’m excited about the iPad, it doesn’t have everything I always wanted, but it will definitely move the ball forward. I personally think the very slightly modified iPhone OS was a mistake, I think there are lots of mistakes and things that I wished were included (like that pony I really wanted). But I’m going to have to reserve judgment until I ca go down to the Best Buy and screw around with one.

oh creator of hot pockets, we praise thee!

I remember being a young lad preparing myself for university I was given a gift from my mother, “C++ for dummies.” The vote of confidence on my status as a “dummy” aside, I read the book with great interest. There was an analogy the author used to explain the idea of classes and what functions they should expose, I’m going to shamelessly steal it (paraphrasing as I don’t have the book with me).

Imagine your son comes up to you and says he wants to make some nachos. You tell him that its fine by you, just go cook them in the microwave, and there is nothing controversial about this statement. Microwaves are actually boxes full of high energy radiation being produced by cavity magnetrons or waveguides, to the end user, the microwave is just a magic warming box. It exposes a very simple interface, some buttons that allow you to enter the amount of time you want to cook something.

This is the essence of an API (Application Programming Interface), wrapping up something complex and possibly dangerous in something safe and easy to interact with. When building code that you intend other people to use someday, it is the part that is most important part, and the part that is easiest to overlook. The problem is that we are often too close to something and too concerned with our use case. If you want to design code for others to use, it requires significant time and effort, and even then you probably still won’t get it right.

Prosper is still undergoing active development, I’m currently agonizing over how I want to expose various execution modes. The solution, no matter what I pick, is trivial to implement, but the api is the most important part. A great api exposes a consistent concept, something that is easily grasped and allows the end user of the api to declare what they want to do without having to worry about how its going to get done. Since good programmers write good code and great programmers steal great code, I’ve modeled the api for prosper extensively off of jQuery. And why not, let’s take a look at two different APIs, the browser dom api and jquery.

  //Let's barber pole a list by coloring every other element blue
  var list = document.getElementById('the_list');
  var highlight = false;
  for(var i = 0; i < list.children.length; i++) {
    if(highlight) {
      list.children[i].style['backgroundColor'] = '#FF0000';
    }
    highlight = !highlight;
  }

Fairly straightforward implementation, but it concerns itself heavily with the “how” of what its doing. Manually traversing to pick the elements it wants, eww.

//Same thing using jquery
$("ul#the_list li:odd").css("background-color", "#FF0000");

jQuery is definitely magic, but this code is great because it let’s you focus on the “what” of what you are doing. How does jQuery go about selecting the right elements and all that? I don’t care, and the great thing is I don’t have to care, and if in the next version of jQuery they find a way to do it faster, I win without having to do anything.

Writing a great api is difficult, you have to divorce yourself from the concrete problem you are solving and look at it in the abstract. Put yourself into the shoes of someone trying to figure out how the api works, and then ask the questions they are going to ask.

• Why do I need to build up this context thing and pass it in?
• How come there isn’t a sensible default for these arguments?
• What dumbass made this thing?

Answer those questions, and keep working at it, strive for elegance and consistency, because then it will be easy for people to learn and use. If your code is easy to learn and use, people are going to want to use it more, and they are going to want to tell their friends about it. Then you can get some lucrative ad campaigns with Nike because of the boffo library you write in FoxPro.

There is a more subtle lesson in all of this though. Any code you write is exposing an api to someone else. “But only I am ever going to use this code!” I hear the naysayers warming up their keyboards for the comments section. This may be true now, but the six-months-from-now-you is going to look back at the you-of-today and wonder what the hell he was thinking.

Get in the habit of making your code easy to use, and expose a nice api. This will endear you to your fellow programmers and help make maintenance easy. Strive to be that guy on the team that writes functions and classes people want to use. Make life easier for your fellow developers and even if they don’t return the favor, maybe they will take you out for a beer. People notice over time that your code is the best to work with, they internalize it, and they start to think of you as a great programmer. That’s a pretty great api to expose to the world.

it cuts the roof of your mouth so the chemicals can get into your bloodstream faster

I took a half-day today, got to sit at home this morning waiting for the Fedex man (who turned out to be a woman). A few weeks ago I got the go ahead from my company to buy an iMac for home (HMB has a program where they will pay for half of your hardware purchase, because they are an amazing company). I got the news yesterday via fedex that my package had arrived overnight from Shanghai in beautiful Anchorage. I was told that the delivery would arrive this morning, asked for a half-day off, and this morning leisurely enjoyed a bowl of Peanut Butter Crunch.

Then I heard the thump thump thump of someone climbing the stairs outside of my apartment and a knock on my door. After subduing my dog Harvey I opened the door, signed the Fedex pad, and took a giant heavy package inside my house. The size of the box blew me away at first, here are the specs of my new iMac.

• 27in Aluminum iMac
• 2.8GHz Quad Core Intel Core i7
• 8GB 1066MHz DDR3 SDRAM
• 1TB Serial ATA Drive
• ATI Radeon HD 4850 512MB Video Card
• 8x double-layer SuperDrive
• Magic Mouse
• Wireless Keyboard

Now I have played with Macs before, I’ve spent countless minutes over the last month or two at BestBuy goofing around with the 27in iMac there. I thought I was prepared for how large this beast is, but I was not. It’s a heavy machine and it is ginormous. The packaging was simple, effective, and beautiful. I had it up and running in about 10 minutes, and most of that time was moving stuff off my desk to make room. A little while back I had purchased a cheap opened-item (although very nice) 22in Velocity Micro Monitor (similar to this one but not identical). When I brought it home I thought it was huge, it looks Lilliputian next to this hulking behemoth.

There have been some reports of the i7 showing up DOA. I’m lucky enough to have not had this happen, my iMac is pretty and working. I turned on the power, answered some questions, and watching “Welcome” fly at my face in multiple languages for a few minutes, and it was up and running.

The Good

• This screen is huge and beautiful, plenty of real estate to take on the job of 2 (maybe even 3) physical monitors
• The wireless keyboard and mighty mouse were pre-synced with the computer and worked right off the bat
• The Apple Remote synced nicely (after I reread the syncing part of the manual and saw the phrase “menu and right button” instead of just “right button”)
• I can now retire my Acer tower to be a HTPC (It’s a little big but I have a cabinet it will fit nicely in)
• The wireless keyboard is a joy to type on
• Opened a terminal and typed ruby –version, it replied with 1.8.7 instead of ” ‘ruby’ is not recognized as an internal or external command, operable program or batch file.”

The Bad

• After syncing my remote I couldn’t get it to do anything, I tried controlling a DVD with it to no avail.
• I only took a half day instead of the whole day off so I can’t play with its beauty right now
• I took some great pictures with my phone, but foolishly left behind my usb cable, a gallery will be posted tonight or sometime over the weekend
• I don’t know what I’m doing. This is the first Mac I’ve owned and so far things seem simple enough, but I’m not at home yet.

There you have it, about 2 years of thinking about buying a new iMac, a few weeks of waiting, and 4 hours off of work later I have my new shiny toy. It is a work of beauty and really a testament to the skill and care the engineers and designers at Apple put into their products. I’m hoping to avoid fanboyism though, I will be running a Vista / Ubuntu powered HTPC and working on an XP Pro laptop everyday for work.

This weekend I will get better introduced to the new member of my tech family, for now though I have to get back to work. Check in Monday for shiny pictures. I hope to do a bunch of how-to’s and screencasts in the future about development on macs and setting things up if you are a developer, so stay tuned.

PS. I have changed the RSS Feed to use FeedBurner, if you experience any problems please let me know at ihumanable [at] gmail [dot] com

having a bully day

This is a very simple rule that I have for solving problems at work, solve them forever. Its not always practical and sometimes you need to bend the rule, but its a great guideline. When I’m presented with a problem at work, I take it as a personal insult, someone could have solved this before and made my life easier but they chose not to and burdened me with it, and I refuse to do that to anyone else.

This has some downsides, you have to put in a lot of effort, and sometimes little things take a lot longer than the “man” thinks they should. There are some upsides though, you avoid technical debt. A lot of coverage has been given recently to the idea of technical debt, how you define it, how you avoid it, should you avoid it and so on. It is one of those nebulous concepts that everyone has a different definition for, we all know what it feels like to run up against some technical debt, its that situation where something that should be simple is needlessly difficult.

Technical debt is not complexity, sometimes doing seemingly simple things within a complex system can be cumbersome, but that’s the price you pay for some other benefit (dynamic forms, automatic mapping, etc.) You know that you’ve hit some technical debt when something is complicated and difficult, but there is no upside.

Boss: Change the text on that button
Dev: Ok, I’ll just update the html
…several hours later…
Boss: Why’d that take so long?
Dev: You see that text is pulled from an i18l file, which is populated dynamically by a database table, that table is autorouted by the orm layer, so I had to change a bunch of configuration entries, then I had to run an update across several tables, some tables were using the name as a foreign key relationship, even though they didn’t declare that formally to the rdbms, so I had to go track down what tables were doing that, and once all that was through I had accidently made a typo and had to go through the whole damn process again.

Debt like this is incurred when you solve a problem for now, not thinking about the future. Solving a problem forever means that as long as the problem domain remains the same that you don’t have to do anything. The issue is that many people misinterpret solving a problem forever as solving all problems forever, and that is not what I wish to promote.

There is an important difference, you should solve the problem domain thoroughly, but your solution should be specific to that domain, don’t try to do too much. There are innumerable problems that someone will take the time to solve for themselves, but give no thought to what happens to the next guy. Coming onto a new project I’ve come face to face with an age old developer problem, rolling on.

Rolling onto a new project is often an exercise in navigating technology to set up a development environment, navigating the corporation to integrate yourself into it, and navigating the team to find a place. All this navigation seems to be on the shoulders of the new person, there are people you need to talk to to get mainframe access. Which people? Where are they? When do I talk to them? How? There are often answers locked up inside someone’s brain, and if you ask the right people you can, like a detective slowly unraveling a mystery, find the answers and get your email and passwords and id badges.

This is a problem that should be solved forever, once the first guy joined the team he should have documented what he did, when, how, why, and that document should be part of team cannon, available as a helpful guide to the next new guy. This rarely happens though, it is a shame, but understandable, new people are struggling to get up to speed on a project they don’t have time for the meta-project of documenting their up-to-speed-getting project.

That is just an example, the next time you are guts deep in a problem that you’ve encountered before think about your fellow developer, and think about how you can solve it forever. The more problems you permanently put to bed, the smoother development can go and the faster you can get your project done.

i know how you feel

Finally! I am finally about to start working at my new project after all those squishy human beings got done drawing pretty charts and signing dead pieces of trees. I now can put myself into the beautiful cold clutches of the machine again and get back to what I do best, code stuff. I’ll be moving from .Net web development to Java middle ware development, and I’m excited to get back to programming.

That seemed like quite the dig at .Net, I don’t intend it to, it’s just been my personal experience. The problem with the .Net projects I’ve worked on is that they’ve been amalgams of third party libraries, and I’ve been in charge of gluing them together. This isn’t a weakness, some would say its a great strength, drop some cash and boom, big problem solved by a nice clean little dll (or 4). I will say that it greatly reduces time to market which is a Good Thing© and that it lets you get down to the customizations that clients spend the big bucks on.

The problem is that I’m a programmer, not a customizer. I like to write code, not tweak little settings here or there (although as a nerd I’m a fan of that as well). The .Net environment always seemed like a bunch of black boxes that I was just trying to lash together in a pretty enough package to call it done. Any actual code I wrote was always just taking business rules and turning them into something a computer can understand. That’s ok, in fact companies make a lot of money doing this type of work, I just don’t as a programmer feel fulfilled by it.

Now though I’m heading into a project where there is a problem without a solution, something that actually needs to be designed, implemented, tested, deployed, iterated, and other fun nerd words. I’m excited to be back to programming, but I’m worried about technological baggage. What is technological baggage you ask, let me find you an example (anonymized, of course).

function Recalculate(...)
{
  if (isNaN(CleanNumber(ctrl.value)) ||
      CleanNumber(ctrl.value) == "")
  {
    ctrl.value = "0";
  }

  var newValue = parseFloat(CleanNumber(ctrl.value));
  var oldValue = parseFloat(CleanNumber(prevCtrl.value));
  var diff = newValue - oldValue;

  ctrl.value = newValue;
  prevCtrl.value = parseFloat(CleanNumber(changedPrevControl.value))
                    + diff;

  //Snip some similar code
  FormatMoneyWithCommas(ctrl, 0, 0, 0);
}

There is nothing wrong with the above javascript it works just fine. But look at it, that’s .Net wrapped in script tags if I’ve ever seen it. There are many non-javascript things going on in this code, anyone familiar with javascript will see them straight away. My intent is not to shame the author of the code or to call it out as bad javascript, it is merely to show that when steeped in a technology it can be very hard to pull yourself out. I picked on .Net but I’ve see plenty of javascript written like java, in fact I’ve gotten actual java code thrown between script tags back from offshore “resources” before.

There is a lot to keep jumbled up in our heads when we are programming, to lessen this burden we adopt naming conventions, and calling conventions, and all kinds of conventions and that is a good thing. The bad thing is carrying your languages conventions into other languages, its a kind of linguistic egocentricity that makes the natives upset.

Now I am trying to purge the .Net from my fingers and get them ready for Java again. I’m sure I won’t remember all the little gotchas, but the important part is to be aware. There are some basic strategies for carrying over as little baggage as possible.

• Google – Go and google Language X for Language Y developers, Language X and Langauge Y can be almost any combination of languages and there is a good chance someone wrote an article, feature matrix, common pitfalls type document for it.
• When in Rome – If you are going into an established project, adopt its idioms.
• Tutorials – Even if you know the language you are heading into, go read a few tutorials, brush up on the basics

I remember the painful period between Java and .Net, being frustrated trying to figure out what the hell a HashMap was called (Dictionary) or wanting to declare what my functions throw. I’m sure I will have the reverse, but the one thing I’m looking forward to is getting back to Eclipse, I love Eclipse, and I will not miss Visual Studio at all.

leaving for somewhere

I’ve been working on a project for the last 5 months, but finished active development about a month ago. I finished in the best possible way, the product shipped, the customer likes it, and there hasn’t been much to do besides the minor bug or feature here and there. It’s a good place to be in, since I’m a consultant it’s also not economically viable. If I’m just sitting here writing blog posts and drinking smooth delicious Diet Dr. Pepper all day, I’m not making money for my company, so they went and found me another project to work on, which I talked about here.

I’m looking forward to starting my new project, but as Semisonic taught us, “every new beginning comes from some other beginning’s end.” (Have to try to pull this post out of the tailspin caused by quoting Semisonic lyrics now). The problem is that when you start a new project, the glitz and glamor of a new project you haven’t learned to hate yet can blind you from the responsibilities of being the guy leaving.

Leaving a project comes bundled up with a bunch of responsibilities. The cliched, “what if you got hit by a bus tomorrow?” question that managers love to ask (because they are too afraid to say, “what if you quit” or “what if I fire you” but oddly enough have no qualms with theoretically knocking you off) actually has some value. The “bus” of leaving this project is barreling down at me, and I have to make sure I dump enough of my brain out that people can still maintain the code I wrote.

If you read my rant / guide to project documentation, here’s a chance for me to prove myself. Throughout the project I’ve dutifully created and more or less kept documentation up-to-date about everything from server credentials to step-by-step deployment procedures. I cannot recommend this approach enough, after reading through some of my wiki pages on these topics it is clear that trying to compile this information after the fact would be difficult if not impossible. So since, ostensibly, everything is done already, what am I left to do?

1. Read through documentation – Projects move fast, things that made sense a month into a project probably won’t make sense 5 months into a project, be sure everything is up to date. Read the documentation with the mindset that you are trying to start working on a project, is it clear, could you set up a development environment, fix a bug, and push out your changes in a day? If not, figure out why not, and fix it.
2. Bug your coworkers – Someone will be around to work on the project, start bugging them to read the documentation, have them go through a dry run of some complex task you normally do, and let them mock your ability to document things properly. It is much easier to have a minute or two of verbal in-person explanation then trying to remember how things work and having a 20 email long thread of questions and answer a few weeks into your new project.
3. Clean house – Those tasks you were putting off doing, get those done, and for fsm’s sake, do it right! There is nothing worse than being knee-deep in a new project to have a past project rear its ugly head, forcing you to dredge up long forgotten knowledge to fix some minor issue.
4. Cut ties – Clients and other developers get used to coming to you with issues, if you are moving on to a new project, let them know about it. Inform them that you will no longer be the contact for the garthok narfler and that they can talk to developer x about it from now on. For an extra touch of class let them know that it was nice working with them.

The way you leave a project is almost as important as the work you did on the project. Rest assured no matter how good a job you think you did, a few weeks after you leave, other developers will be cursing your name. Your job as you leave is to make sure that those angry expletives are few and far between and that you can rub it in their face when they complain about this problem or that obstacle with the fact that you left them very clear documentation on how to handle such a situation.