Tag: Invent And Simplify

Winging It

Winging It

By | | Comments 0 Comment

I keep a running list of topics, but today I’m ignoring it and shooting from the hip. A stream of consciousness post, if you will.

Yesterday evening I added a couple new features to an Ionic app. I’m really appreciating the improvements brought by Angular 2; it’s made the architecture quite a bit cleaner than before, and adding new capabilities is quick and painless. I still have a ways to go before I fully grok observables, but I’m getting there.

Was talking with a musician friend of mine on Sunday about the difficulty of making meaningful progress on a project without having at least 2 continuous hours of focused time to work on it. Half hours here and there don’t cut it. That’s an important truth both for us nerds who try to do side work in our spare time. It’s also an important reminder for non-nerds who feel the need to interrupt the nerds in their charge.

Speaking of interruptions, nearly 6 hours passed since I wrote that past sentence due to an urgent production bug. Who knew when I woke up this morning that by noon I’d be decompiling Java classes from a production server. Yay!

Every. Single. Time.

Every. Single. Time.

By | | Comments 0 Comment

Want to know what happens if you don’t follow the Boy Scout Rule of software development? This.

That being said, it can be really easy to get into a vicious cycle of constant rewriting and never releasing. We’ll talk about that tomorrow.

Toaster Apps

Toaster Apps

By | | Comments 2 comments

Developers may like to write software, but that doesn’t mean we want to fix your computer (or even know how to fix it, for that matter). Nevertheless, we’re often asked, and sometimes try. A former co-worker of mine used to complain about his neighbor’s constant IT requests. “Toaster Lady” he called her, because she’d say “I want my computer to ‘just work’. Like a toaster.”

There’s a lot for those of us in the software industry to unpack in a statement like that. In particular, I was reminded this weekend that getting software applications to the point where they “just work” can be incredibly difficult.

Part of this relates to the phenomenon of simplicity that I’ve written about before. It takes effort to design interfaces that are both simple and functional for a broad range of users. And there’s a temptation to put aesthetics before all else. Resist it (and read Don Norman’s seminal work on the subject).

Implementation of a simple design is not simple. In fact, it’s often tougher to build code that does simple things well, because nothing is simple with computers. Beneath the Google search box lies an unimaginable stack of data, algorithms, networks, and hardware, all of which works together in concert to find that perfect cat video. It takes an army of people to keep it all running (because everything is always breaking all the time). Not to mention the even larger army of people who designed the individual elements, who could only do so because of the work of even more people whose research and ingenuity gave rise to computing machines in the first place. Simple search? Ha, there’s no such thing.

And the work required continues to grow exponentially into testing. All possible permutations of use cases must be tested to flush out potential problems. Have two buttons? Well, that’s four tests. Add a third, now you’re up to eight tests. Oh, and even that isn’t covering that one weird case where if you press the same button fifty times in a row and then hit button three the software crashes. Now expand that to a box with arbitrary text input? The possibilities are staggering (but not endless; there’s a big gulf between large and infinite, but that’s a post for another day).

Consider all of this next time your technology fails you, and be thankful that it ever works at all.

Wisdom Of Pascal

Wisdom Of Pascal

By | | 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.

The Holy Grail

The Holy Grail

By | | Comments 0 Comment

As of today, I do not think there is a better general purpose language in existence than Python. With few exceptions, it just feels “right”, and without fail writing it makes me happy. Here’s just a couple of my favorite features:

Clean syntax

Python eschews block delimiters in favor of strict indentation rules, which both keeps the code more readable, and forces good formatting. It also requires a minimum of special characters, enhancing readability even further. I work with Perl extensively in my day job, and just look at how much grosser it looks than the equivalent Python:

if ($enemy == 'klingon') {
   firePhasers();
}
else {
   openHailingFrequencies();
}
if enemy == 'klingon':
    firePhasers()
else:
    openHailingFrequencies()
Implementational flexibility

I’m not sure that’s actually a word, but what I mean to say is that Python is a solid choice no matter the design approach you want to take. Writing a simple procedural script? Python does that. Taking an object-oriented approach? Python does that too. Want to dabble with a functional style? Oh yeah, Python’s got your back.

While the purists might say Python isn’t the ideal choice for any of those scenarios, I say it’s probably good enough, and in the real world I’d rather be an expert in one language than a novice in three.

Extensive PACKAGE library

I’m continually amazed at how much functionality is included in Python’s standard library. It makes writing code so much quicker. And if a feature isn’t in a default package, there is a massive ecosystem of third party libraries.

In my next couple of posts I’ll share a few of my favorite of these packages.

To Be Fair

Python isn’t perfect, and there are a couple things I don’t care for. For example, take its ternary syntax:

action = 'punch' if captain == 'Kirk' else 'talk'

I’m generally a fan of ternary operators because of their concision (which is a word I just learned), but the ordering of this construction feels awkward. See, I can be unbiased!