Deliver Results – Page 5 – Making Of Things

Finish

By Jud | May 12, 2017 | Comments 0 Comment

Does anyone else have a hard time finishing a project? I suspect it’s a common theme among developers. At the beginning, a project is fresh and new, and it’s fun setting up new tools, cleaning the slate, and getting that first prototype up and running. But as time goes on and the needed features pile up, excitement wanes. Your clean initial bits of code have been cluttered by refactoring and redesign as requirements evolved and unexpected complexities emerged. What was once new is now routine when you’re adding feature 42 of 50, and by the time a task is 90% done, you’re tired of looking at it and desperate for something different.

You’re not alone in this feeling; it’s a well documented phenomenon across a variety of creative disciplines. But fight that tendency, my friends, and push through, because a finished imperfect project is better than a perfect unfinished one.

My theory is that the inability to finish is a combination of the 80/20 rule, unavoidable code rot, and the Creator’s Curse. Naming these issues is the first step to mitigating them, so don’t be afraid to call them out when you see them, both on your team and especially in your own work.

I know personally it was a barrier to getting this blog going again, and it’s a problem I still fight. Am I totally happy with this post? No, not really (writing it while trying to listen in on a teleconference doesn’t help). But I’m clicking publish anyways.

Babies With Great Personality

By Jud | May 4, 2017 | Comments 0 Comment

Yesterday I was speaking with a fellow engineer about the state of our new user interface implementation. We’d crossed a major functionality threshold, but there were still several obvious bugs. I argued that the significance of the functions that were working merited deploying to our integration server for others to see, but he resisted saying that he’d rather wait until a couple of the blatant problems were ironed out.

The above is a common conundrum for developers. Put your work out there for others to see too soon, and they’ll be quick to point out all the flaws. Wait too long, and managers start breathing down your neck because they’re not seeing tangible results.

Personally, I think the wise manager understands the idea of a work in progress, and should appreciate seeing said progress without getting overly critical of early blemishes. It’s a bit like posting photos of a newborn baby. Obviously everyone loves their little nugget, but reality is most newborns aren’t super cute in their first couple of days. But would anyone ever dare point that out to proud parents? Let’s surely hope not! The birth of a child is a momentous event to be celebrated; there’s plenty of time later for the kid to grow into his adorableness.

Likewise a software application. Publish early, and let that baby grow!

Wisdom Of Pascal

By Jud | April 21, 2017 | Comments 1 comment

“I would have written a shorter letter, but I did not have the time.”

Blaise Pascal was a smart dude. Much of what he had to say is surprisingly applicable to software development (which is why if you show me a well-read developer I’ll show you a good developer). The above quote came to mind yesterday during an all-hands meeting where we were discussing our company core values:

“We build elegantly simple software.”

I love that sentiment. But make no mistake: elegance and simplicity take more time to build than complexity. This is true up and down the process, from prototyping, to requirements development (holy cow is this step often rushed; we’d do well to heed Mark Twain here), to implementation and testing.

My first task after moving to San Diego was to help a development team push through a particularly challenging set of features for a digital mapping system. Twelve hour days and weekend work was expected, and all tasks had to be done as quickly as possible. The technical architect had put together a mockup of a few of the screens using a prototyping tool, and unfortunately the quickest way to make those screens a reality was to copy and paste the auto-generated XAML (sort like Android’s XML-based UI markup, but for C#) and then tweak it. This led to a ton of duplication, with hard-coded screen positions everywhere. By the time we got the initial release of the application to the test team, it had become an unmanageable nightmare. But we limped along, duct taping bugs as they came up.

Then came the back-breaker, under the guise of a single requirement: “by the way, this needs to work in landscape as well as portrait orientation”. Just like that, our brittle implementation became untenable. It needed a complete re-write.

I was assigned the task, and (thankfully) given a month to do it. My delete key was never busier as I learned how to abstract and consolidate the XAML, replacing tons of repeated values and cleaning up duplication. Turns out XAML is pretty easy to author and has plenty of features for writing clean and responsive implementations, but no one had bothered to learn it. By the end of my process, in addition to adding a landscape capability, I’d shrunk the code base by over 90%, and gained a near 5x boost in performance to boot.

The moral of the story? Well, actually there’s two. The first is that using SLOC is a dumb measure of productivity (I was averaging about -10,000 lines written per day or something like that). And the second is that the best developers delete as much code as they write. Maybe even more. Refactoring isn’t a separate step on the task list; it’s part of every task. Yes it takes more time. Yes you might need to let go of your ego and trash that super clever function when it becomes unneeded. But your product will be better for it.