Feeds:
Posts
Comments

Archive for the ‘Software Development’ Category

I believe that you can learn a lot about people through the things they fill their heads with. Over time the mechanisms for this process have grown in number and availability. Once people would travel great distances seeking out teachers. Of course if you were powerful enough you could have them come to you. Once we managed to get the teaching down in permanent (well mostly) form, you didn’t actually need to bother with the whole physical presence thing. Still the needing the scribe thing made this practical only for the silly rich. By the time we get to the 20th century the super clever public library idea meant that you could recommend a book to someone without running the risk that their dog would eat the only copy for a thousand miles. The mid 20th century added audio and by the end video to the menu. With the advent of the internet, we could not only find materials to borrow from libraries with ridiculous ease, but could reserve it and get an email when it was ready for pickup. Then came the Kindle, Zinio, Netflix and the iTunes store. Now if someone is ingesting some bit of knowledge, in all likelihood, you can too (and within minutes).

So, what’s with the Burke-ian prologue?

Well, I was reading The New Yorker‘s article The Shape of Things to Come, about Jony Ive and the future of Apple. Among the bits of past, present and impact; was a fascinating bit. Ive was watching Moon Machines [iTunes Store]. Not expected that.

I’ve always been a bit of a space wonk, so I was interested just on the face of it. What I found fascinating was that a person born in 1967 England best know for early 21st century industrial design saw something of interest in a series dedicated to the United States’ Apollo program.

Having now watched the series, there are things that jump out at me. As with every time I take in something that’s been recommended (if person with the time constraints of a SVP at Apple mentions that they see value the spending time, that’s a hint one would be ill advised not to take advantage of), I strive to understand how it relates to the person, their work and goals. Ive’s comment speaks volumes.

… like the Apollo program, the creation of Apple products required “invention after invention after invention that you would never be conscious of, but that was necessary to do something that was new.”

The Apollo program was a tech start-up writ large. The goal was abstract; the time tables unyielding; the cost astronomical (literally); the toll on people and their relationships severe. In the end, the successes were ascendant and the failures devastating. The six episodes take on major aspects which had to work together in order to assure the success of the program.

The lessons of Apollo are applicable to endeavors in science, business, politics and design. Issues of control, quality, planning, communication and contingency are laid bare. As are their failures. Of particular distinction are the moments of crisis. Unlike anything before or since, we have documentation of and visibility into the people who stepped up to lead their teams and the processes through which they overcame them.

In an era of ever-increasing abstraction and the misplaced belief that you don’t actually need to understand how things work in order to produce something of quality, Moon Machines provides timely lessons. The quality of the end product begins with the confluence of domain and technology, not the application of one to the other. The speed and manner of disposing problems during a crisis depends greatly on the depth of understanding extant in the team of the two questions: What do I have? and What do I need? As well as the understanding of how to get to the latter using the former.

In the end, I have a greater admiration of those involved in Apollo thanks to a comment by Jony Ive.

Read Full Post »

It’s been five months since Apple’s Worldwide Developer Conference ended. This year the WWDC iOS application had the session videos available sooner than ever. I’d been watching them during my commute to and from Portland’s downtown. Well, this past week, I finished watching the last one. And with 107 videos, it’s Apple’s version of Netflix putting up a few years of Doctor Who episodes for people to gorge on.

Truth be told, I would have finished a month ago. So, what was the hold up? iOS 8 released. In doing so, it revealed that some change in the OS caused the WWDC app to crash when you tried to view a video. Very sad. The really unfortunate part is that I was only four videos away from having watched them all.

Well, I’m happy to report that the WWDC app is now working fine and I’d encourage anyone who’s doing OSX or iOS development to take advantage of them. There is a tremendous amount of information on the latest tools, technologies and techniques. Swift and Metal feature prominently.

Now, I’m not saying that these are all Jobsian quality presentations. As much as I appreciate that software development is a global endeavor, whoever decided that someone with a pronounced French accent should be littering his presentation with the word banana should be forced to watch that session from beginning to end. Subtitles would also have helped some sessions.

All-in-all these presentations are well crafted and delivered. Apple also continues its tradition of providing substantive sample code. Nothing is worse than code snippets that don’t convey the true flavor of using an API as you would in practice. Happily gone are the days when the AOCE (Apple Open Collaboration Environment) documentation was 1200 pages of paper with no index. Not the best way to pick up a new technology.

So if you need a break from watching the original run of The Tomorrow People, the WWDC sessions are there for you.

Read Full Post »

In the mid-90s I was introduced to the phrase “Compile it. Link it. Ship it. Debug it.

Yeah, it’s sadly funny, but what’s that got to do with QA not being a speed bump?

Once we developed software, then we had waterfall, then agile, then test-driven development. Next? Who knows. Here’s a clue. We’ll still be developing software.

In a world of would be Sherlock Holmes’, we are in desperate need of more John Watson’s. And like the classic pair, the end product is much better when they are working in a tightly coupled fashion. And by that I mean both geographically and temporally. Let’s look at some common software development models of developer/tester interaction designed to fail.

Remote Test

There are some who believe that the phone/IM suffices as a mode of communication when developing complex software. Unfortunately, there is a proportional relationship between the distance between the developer and tester; and the scale of misunderstandings. “Frog protection” anyone? Nothing brings a developer back to reality from Nerdvana faster than someone standing in front of them waiting for them to explain exactly what it is that the software is supposed to be doing. Out of sight, out of mind.

Software First, Test Plan Later

This is especially interesting when QA has the responsibility of saying that the story associated with the feature is working. Let’s make it even more fun by saying that we can count story points when the developer says they’re done, but we won’t actually get QA sign-off until the next sprint. Technical debt-ville.

Unit Tests Mean We Can QA Later

Everyone who believes that they can proof read their own documents, stop reading now. The hallmark of a great tester is that the first thing that comes to mind when they look at your software is the last on yours. How can I break this. Developers struggle to get the “happy” path working. Where do most problems come up? The “sad” path. If people do get to write unit tests, and the code is structured to allow unit tests, it’s more likely than not that only the happy path will be tested. After all, it’s QA’s job to test what doesn’t work right?

Testers as Second Class Citizens

Holmes may be brilliant, but Watson is the proxy for the rest of humanity. You know, the ones who don’t keep heads in their refrigerator. The ones who we expect to, you know, pay money for the software. Not everyone reads Shakespeare in the original Klingon. Testers keep the “pizza under the door” crowd honest. Am I being a bit harsh on developers? Perhaps, just a wee bit.

Beta Test as Test

Throwing it over the wall taken to the extreme. Well, not quite the Google, “it’s not a product, it’s a beta” extreme, but GMail does pretty much set the goal post for that one. Guess what, when a potential customer gets hold of a beta, ninety percent of them will treat it as though it’s a complete product. Do you want your bank using your “beta as test” software? Would you use a beta compiler for your grandmother’s pacemaker? How about a drone? The close cousin to this is the weenie move of calling your software 0.9 for a decade and thinking that somehow insulates you from your commitment issues. Tossing your software out to the world without having the courage to “own it” is just lame. Doing so because you can’t be bothered to do the work is unprofessional. “Lost your company’s data? You can’t complain. It’s beta software afer all.”

It’s Time to Start Treating Testers Like the Partners We All Desperately Need

I’ve had the privilege to work with some very gifted individuals who time after time brought code, that I was sure was solid, to its metaphorical knees. They helped me to explain the complex in human terms. Treat them well and they will improve both the end product and the process. Remember, QA is not a speed bump, a nuisance to be endured. It is the whetstone that keeps the knife keen.

 

Read Full Post »

« Newer Posts