Kirk's Planet

April 03, 2012

Kirk's Gartner Blog

The Android Dilemma – Fragmentation

The best thing that Google can do for the Android ecosystem is develop a world-class piece of hardware that runs the Android operating system. Unfortunately, the worst thing that Google can do for the Android ecosystem is develop a world-class piece of hardware that runs the Android operating system. Yeah, that puts Google in a tough spot!

Google’s recent purchase of Motorola Mobility is certainly a patent play, but it also gives Google the luxury of building an Android device should they choose. They’ve already announced they’ll be delivering a Google branded tablet, though they’re partnering with Asus, not using the Xoom. Perhaps this is just the first step. Next up? A Google branded smartphone where they “partner” with Motorola Mobility. All just pure speculation at this point, but still interesting to ponder.

Given the existing fragmentation of the Android ecosystem, this may not be a bad idea. It’s one thing when developers start complaining of fragmentation. It’s yet another when consumers start complaining because apps don’t work. In the end, fragmentation is killing the Android platform and Google has to address this issue ASAP.

With Google developing their own devices, they’ll have complete control over the experience (ala Apple), but it’s sure to drive away device manufacturers who have built atop Android. Hey, maybe webOS isn’t dead. After all, it’s a great mobile operating system that’s now open source. More on that another day.

If Google chooses not to build their own smartphone, they have to take at least two important steps. First, they have to gain control over updates to the Android operating system. Leaving updates in the hands of network operators and device manufacturers is the cause for this fragmentation. Second, they have to ensure that device hardware profiles created today possess the ability to run future versions of Android for at least two years (ie. the length of a typical network contract). Preferably longer.

If Google doesn’t take one of these two steps (i.e., their own device OR gaining more control) fragmentation on the Android platform will persist. And once users start suffering, that’s not a good thing for Android. In the meantime, if you’re shopping for an Android device, buyer beware. You can still purchase a device running Android 2.1 (aka. Eclair), which first hit the market in 2010 and is over two years old. If you happen to purchase one of these devices, don’t expect an upgrade to Ice Cream Sandwich (v. 4.0). And if you’re developing for the Android platform..well…good luck with that too. You’d best understand market share and try limiting your options.

March 26, 2012

@kirkk.com blog

Java With a Bit of OSGi - The Book

I’m dancing. By god I’m dancing on the walls. I’m dancing on the ceiling. I’m ecstatic. I’m overjoyed. I’m really, really pleased.
- An excerpt from the Foreword by Uncle Bob (aka. Robert C. Martin)


My book, Java Application Architecture: Modularity Patterns With Examples Using OSGi is now available. Uncle Bob and Peter Kriens each contributed Forewords to the book. The book itself is part of the Robert C. Martin series. The book is intended for all software developers interested in designing better software using modularity. Though the examples use Java, the techniques can be applied to other languages and platforms, such as .NET, with relative ease.

Even if you’re not using OSGi (or perhaps not even familiar with OSGi), I’m confident you’ll find the book valuable. The book (and patterns) has been designed to allow you to realize the benefits of modularity whether you’re using a module framework, or not. As Uncle Bob says in the Foreword, “This is how you build a Java application, people.” Peter sums it up nicely too, in saying “This book…will give you a view into the magic of modularity.

You can order it online at Amazon (print edition & Kindle edition), iBooks, InformIT, or a number of other publishers. For more details on the book, please see the book’s website. Over the next couple of weeks, I plan to post a sample chapter or two that will give you a feel for the book’s contents.

Here’s what a few people have to say:

  • “The fundamentals never go out of style, and in this book Kirk returns us to the fundamentals of architecting economically interesting software-intensive systems of quality. You’ll find this work to be well-written, timely, and full of pragmatic ideas.” Grady Booch, IBM Fellow
  • “Along with GOF ‘Design Patterns’ - ’Java Application Architecture’ is a must own for every enterprise developer and architect, and on the required reading list for all Paremus engineers.” – Richard Nicholson, Paremus CEO & President of the OSGi Alliance
  • “In writing this book, Kirk has done the software community a great service: he’s captured much of the received wisdom about modularity in a form which can be understood by newcomers, taught in Computer Science courses, and referred to by experienced programmers. I hope this book finds the wide audience it deserves.” Glyn Normington, Eclipse Virgo Project Lead
  • “Our industry needs to start thinking in terms of modules – it needs this book!” Chris Chedgey, Founder and CEO of Structure 101
  • “In this book Kirk Knoernschild provides us with the design patterns we need to make modular software development work in the real world. While it’s true that modularity can help us manage complexity and create more maintainable software, there’s no free lunch. If you want to achieve the benefits modularity has to offer, buy this book.” Patrick Paulin, Consultant and Trainer at Modular Mind
  • “Kirk has expertly documented the best practices for using OSGi and Eclipse runtime technology.  A book any senior Java developer needs to read to better understand how to create great software.’ Mike Milinkovich, Executive Director Eclipse Foundation
I’d like to thank all of you who helped me along this journey. I hope you enjoy the book.

Kirk's Gartner Blog

A Mobile Kata

A programming kata is a programming exercise that you repeat many times over. A programming kata is useful for a few different reasons.

  • It helps you learn a new programming language or framework.
  • It helps you hone your skills with a language, framework, or tool you already use.
  • It can provide fresh insight on how you might use your existing tools by applying techniques you’ve learned using an alternative tool.
  • It can help you evaluate and compare different frameworks and tools.
  • It can serve as a reference implementation you use to teach others.

A kata isn’t exclusive to just programming, however. In fact, the term kata originated in karate, and you can use the concept of a kata to help you learn new tools, refine processes, or just about anything else you want to get better at.

One kata I’ve applied numerous times is my Loan kata. The Loan kata accepts an amount, term, and rate and calculates the monthly payment for a loan. Variations of the kata calculate the amount each month applied to prinicipal and interest. Over the next several weeks, I’m going to use the Loan kata to develop different types of mobile applications. Each time, I’ll post a blog entry that illustrates what I’ve done and shares some of my findings. Right now, I intend to do the following:

  • Create a mobile web app using JQuery Mobile.
  • Create a mobile web app using Sencha Touch.
  • Create a resident mobile app using PhoneGap.
  • Create a resident mobile app using the iOS SDK
  • Create a resident mobile app using the Android SDK
  • Create a resident mobile app using BlackBerry SDK
  • Create a resident mobile app using Windows Phone SDK

If you’re interested in seeing another tool or framework used, let me know and I’ll add it to the list. I don’t have a timeline to complete all this, and it will take me several weeks to pull them all together. But stay tuned for some programming fun!

March 13, 2012

Kirk's Gartner Blog

Traceability – Give Me a Break!

Today, I got an e-mail about a webinar on requirements traceability. Come on, give me a break! Conceptually, the goal of traceability is a noble one. The ability to link artifacts back to stakeholder needs and forward to the design artifacts, source code and tests that realize those requirements help us, among other things, understand and assess the impact of change. But there’s some hidden challenges that blow traceability right out of the water.

There are two key requirements with traceability.

  • Related artifacts must be linked together. 
  • Linked artifacts must maintain fidelity.

Every software artifact is an expression of some requirement. On a typical software project, a single requirement is expressed several different ways (use case, business rules, user story, test case, class diagram, source code). But regardless of how it’s expressed, it must convey the same meaning across all linked artifacts. That is, it must possess fidelity.

Establishing the links between artifacts is the easy part. Managing these relationships going forward is virtually impossible. We can only maintain fidelity across artifacts if we synchronize the artifacts anytime something changes. We all know that this doesn’t happen. When a test plan changes, we rarely go back and update requirements documentation. When the source code changes, we rarely update the design document.

The primordial force that makes traceability unattainable is the reliance on the power of human discipline to ensure that the correct links between artifacts are established and that each artifact maintains fidelity with other linked artifacts. The more things change, the more discipline that’s required. Most teams simply don’t have the time to maintain that discipline. The result is the outdated and irrelevant documentation that plagues many projects today. Again, establishing the links between artifacts is easy. Ensuring linked artifacts are synchronized and maintain fidelity is hard.

Many tools claim to offer support for full lifecycle traceability. Be careful. What many offer is the possibility to establish links between artifacts, with no guarantee that the correct links have been established and that the artifacts offer a consistent expression of a requirement. Traceability without fidelity will not make you happy. 

So, is traceability attainable? Absolutely. But only if related artifacts are linked and the artifacts convey the same meaning. Since we don’t possess the discipline to do this manually, the only way to ensure both is through executable artifacts. Executable artifacts are artifacts that are executable against another artifact. Executable artifacts establish a link and enforce fidelity. The simplest example is an automated test against the code. If the code changes, the test may break, resulting in a lack of fidelity. Fortunately, this lack of fidelity raises an error condition and make it visible to the team, forcing them to fix the problem (i.e., synchronize). 

Until tools support executable artifacts, the promise of traceability will go unfulfilled.

If you’re a Gartner for Technical Professionals client, you can read more about this idea in our SDLC Reference Architecture and Requirement Management template.

 


March 01, 2012

Kirk's Gartner Blog

Mobility, Architecture, & Code

It’s been a while, but it’s good to be back. After a year-long hiatus, I’m back in the blogging saddle. This first post is just a quick “hello” and a shout out to let everyone know what you’ll find on my little corner of the Gartner Blog Network. You’ll find me discussing three things specifically:

Mobile Development: Most of my research these days is focused on mobile application development. This includes the mobile web, cross platform frameworks, and the native software development kits (SDKs). If, like me, mobile development is your bag, you might find the the following Gartner documents a good place to start – Mobile Web Applications, Cross Platform Mobile Development Frameworks, and Mobile Applications: Native, Cross-Compiled, Custom Container, Hybrid, or Web.

Software Architecture: For several years, I’ve taken a keen interest in software architecture. In fact, this interest is one of the reasons I haven’t been blogging as much lately. I’ve been working on a separate writing project that is just wrapping up. I’ll make an announcement on this soon. But for those of you already familiar with some of the content on my previous blog, rest assured you’ll find similar content here. I mean seriously…it’s been way too long since I’ve written anything about OSGi, don’t you think?

Code: Through all the principles, practices, patterns, disciplines, and methodologies we discuss ever so frequently, none of it would matter without the code. Seriously, it’s pretty tough to have a software system without the code. Since I still stay pretty close to the code, taking a bit of time each week to hone my skills, you’ll find my posts often include a bit of code to drive a point home or simply demonstrate how to do something.

Oh, I suppose every once in a while I’ll stray from these three topics and discuss the software development process, a programming language or two, or just technology in general. It’s a geeks world, you know. If these topics interest you, why not subscribe to my feed and participate in the discussion.

I’m excited to be back blogging again.