by Kirk Knoernschild | April 3, 2012 | 8 Comments
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.
Category: Mobile Tags:
by Kirk Knoernschild | March 26, 2012 | Comments Off
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!
Category: Applications Mobile Tags:
by Kirk Knoernschild | March 13, 2012 | Comments Off
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.
Category: Software Development Process Tags:
by Kirk Knoernschild | March 1, 2012 | 1 Comment
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.
Category: Applications Mobile Platforms & Software Architecture Tags:
by Kirk Knoernschild | August 12, 2010 | 4 Comments
“Forward and sustainable progress can only be measured through a software system that works. There is no other way!”
Those are the words I uttered at our recent Catalyst conference in San Diego when debating the merits of agile development on stage with a colleague.
Requirements documentation, architecture and design models, and test plans may provide value, but they do not offer accurate insight into the current state of the project. While we may value these artifacts, we must value working software more. Without a system that works, there is no way to be certain that the development team is moving in the right direction. Continuing to develop and add new features to a software system that doesn’t compile, or whose tests fail, will only steer the development team further off course, away from their intended destination. Without question, it is counterproductive to add code to a system that doesn’t work. A software system with a multitude of compilation errors or failing tests only offers a false sense of security that the team is making progress.
The prime directive of software development states that a software system should always compile and its tests should always execute successfully.
From the moment the first line of code is written to the moment the team gathers for the “go/no go” meeting, and everywhere in between…the system must work. The software development team should strive to ensure the system can be built, tested, and executed at any point in time throughout the development lifecycle.
The prime directive assures the development team that they are building a system exhibiting the functionality their users demand. It ensures they are developing a system that performs, is secure, and is dependable. How so? The system is always functional, so it can be tested throughout the lifecycle. Customer demonstrations can be held that ensure the software meets the needs of the users. Important feedback garnered from these demonstrations allow the development team to adjust their course. Problems aren’t allowed to fester in the system for prolonged periods of time. As issues arise, they are dealt with by the development team. The result? No problem is ever older than the last successful build.
Of course, the prime directive has implications. If at any point in time the software is broken, it must be the priority of the development team to resolve the situation as quickly as possible. The software should never be left broken for an extended period of time. This can seem counterintuitive, especially for teams with severe deadline pressures. The prime directive demands discipline. And it is with this discipline that the development team is able to ensure sustainable and forward progress throughout the duration of a project.
There are many practices, agile and otherwise, that development teams adopt to improve quality, speed delivery, and increase project transparency. But each of these practices depends upon the fundamental notion that the software works. That is how it should be. That is how it must be!
Category: Agile Tags:
by Kirk Knoernschild | August 4, 2010 | Comments Off
Agile transitions are tough. Real tough! But there are some important practices a team can employ to increase agility without undergoing a massive agile transition effort. One of these practices is Continuous Integration (CI), and I’m hard pressed to imagine a software development team that wouldn’t benefit from a sound CI strategy. After all, if we cannot prove that a software system works, we must question if we’re truly making progress by adding code to a broken system. In fact, leveraging CI is one way to launch an initiative to increase the agility of a software development team.
On the Test Early blog, there’s a great little parody that offers a play on the proverbial rhyme, “For Want of a Nail”, which illustrates how even the smallest of actions (or lack thereof) can have significant consequences.
FOR WANT OF A BUILD
For want of a build, a test case was not executed
For want of test case, a defect was not detected
For want of a defect report, a bad release was promoted
For want of a good release, a strategic customer was lost
For want of a customer, a development team was reduced
For want of developers, a product stagnated
For want of a product, a company was lost
And all for the want of a build…
While the result as played out here is pretty extreme, the essence of CI is captured quite well. Emphasizing quality throughout the development effort, in lieu of attempting to verify quality at the end, will likely result in a much higher quality product. In other words, Build Quality In. CI helps us accomplish this feat through frequent builds and test execution that allows us to verify the system is always in a working state. Additionally, other important lifecycle activities are enabled that provide the important feedback necessary to ensure we never stray to far off the intended course.
Category: Agile Software Development Process Tags:
by Kirk Knoernschild | June 11, 2010 | Comments Off
It’s exciting to be part of GBN, and I look forward to sharing opinions with each other. Make no mistake…this is a technology blog. But I hope to blog about technology topics in a way that helps folks understand the strengths and weaknesses of the technology, as well as helping them make the important decisions surrounding the technologies they’ll use going forward. I hope you’ll join me in exploration, and contribute your views.
Here’s a bit of what you can look forward to reading about in my little corner of the GBN world, along with my brief views on each. Over time, we’ll delve into each more deeply.
Software Development Processes and Practices
I’m an ardent believer that agile development methods and practices are *always* good, they do scale, and are a critical success factor for large teams. While that may sound overly zealous, I cannot think of any situation where slow, brittle, and resistance to change are beneficial attributes. Granted, my definition of agile may be slightly different from others, so this will be fun to explore.
Platforms, Development Frameworks, Software Architecture, and Modularity
The application platform that we’ve grown accustomed to over the past decade is undergoing transformation that stands to affect everyone from the developer to the folks in the data center. There is a lot of buzz surrounding the cloud, but there is also significant innovation elsewhere that promises to dramatically alter the tools we use to develop software. Dynamic languages that promise improved productivity and functional languages that promise improved performance are two examples. First class support for modularity (e.g., OSGi) that brings with it platform componentization and the opportunity to rightsize the platform is another. And each has a significant impact on software architecture of the future.
Rich Mobile Application Platforms
By now, I suspect you are familiar with these new breed of mobile devices garnering so much attention. Hardly a day goes by without an earth shattering announcement. The battle between Apple and Google is exciting to watch. Yet beneath these very public disputes lie an interesting set of dynamics. For instance, is Apple’s curated ecosystem really the devil? Or might the fragmentation of the Android platform be a bit more concerning? And each affects how you develop rich mobile applications for the respective platforms, albeit in different ways.
In the mid-1990’s, rich client technology was the rage. Remember PowerBuilder, anyone? Of course, the web changed all that, offering a near ubiquitous platform for delivering the corporate brand to consumers. Unfortunately, web technologies presented new challenges. Rich internet application technologies (RIA) such as Ajax and Flash helped overcome some of the user experience problems, but others persisted. The lack of local storage and inability to access applications in the absence of an internet connection are two examples. While new technologies such as Silverlight and AIR promised to finally overcome these challenges, HTML 5 aims to do the same. And on the horizon looms a rather interesting battle that will redefine the web.
While the above topics are my primary interest, I cannot promise that I won’t occasionally stray and discuss other topics, as well. It should be fun.
Category: Mobile Platforms & Software Architecture Presentation Software Development Process Tags: