Luck in Software Development, Part 2
Tags: programming, coding, php
Published: 2018-04-22 13:23:37

---
title: Luck in Software Development, Part 2
published: true
description: Software Development isn't purely about skill
tags: Programming, Coding, PHP
---

In my [previous post](https://dev.to/dexygen/luck-in-software-development-part-1-4f2) I wrote about how lucky I was that in my first ever professional programming position, when I accidentally crashed all our Unix systems, we already had a consultant on-site for upgrading our SCO OS.  Fast forward about 10 years to when I was already a solidly intermediate, if not verging-on senior, developer for another instance of me "Luck in Programming."

There was even some luck in me landing the particular position, in that I was going to get to use a framework I wrote myself, [that framework being "barebonesmvc-php"](https://github.com/dexygen/jackrabbitmvc) (now jackrabbitmvc).  I remember in phone discussions before taking the position I mentioned not once, but twice, that my framework was just 60 lines of code, and they didn't say yes, but they didn't say no either, so that was good enough for me.

But the real luck is what transpired over the next month or so.  For one thing I was tasked with converting about 75 HTML files to PHP in just one month's time.  I don't think I was even a week into the process when it dawned on me that I could put object-orientation to work; almost all of the files were largely cut and paste jobs and fell into one of the following three categories:

1. Image-related
2. Photo-related
3. Video-related

So I created a "media" parent class that did most of the heavy lifting and had each of the three child classes above inherit from that.  This cut down on the size of the code base, which, as it turns out, was crucial.

I just barely made the deadline: I remember a day or two before I informed my manager that I had 10 or 15 files to go, and he said maybe we'd have to push the date out.  But then I wrapped up maybe all but 2 or 3 of the above in the next couple of days, and he said that was good enough.

So off to the client I went to "burn" my code on to a settop-box-like embedded device.  But after a short while the engineer for the client told me the code wouldn't fit.

Wouldn't fit?  I'd never been told of such a requirement.  The company I was contracting for probably just took it for granted: they primarily did embedded work.  I on the other hand was primarily a web developer and never before in my career had I had a requirement that my code and/or accompanying assets could only consume so much disk space.

Luckily I'd left some unnecessary odds and ends in the code/assets base, and by deleting a few images amounting to maybe 100kb we were able to get the code down to a sufficient size that it could be burned to the settop-box's hard drive.  But I think the biggest way in which I got lucky was that, given the extremely tight deadline, I felt I didn't have time to learn enough about some established PHP framework to incorporate that: had I done so, I would *never* have gotten the code down to a small enough size while sitting at the client site.  So my little 60-liner was perfect for the job, and this is probably why management at my position did not say no to it.

I guess the real take-away from this is to be more pro-active in obtaining requirements, because you can't always be sure you are being given them all up front.