Tag Archives: Software

What is definition of “Open” ?

Posted on by

There are lots of discussions happening in the blogosphere about what is the definition of Open (when talking about Android vs. iPhone). Many of these discussions are around open source software (OSS). But there are other views as well to be considered when talking about the “openness”.

There is open from the open source software (OSS) point of view. From this perspective, the Android stack is not 100% open (parts are proprietary by Google or 3rd party) and the iPhone is not open at all. This is a technology view.

And there is open from the legal perspective, in this case, Android is much more open than iPhone (as Apple doesn’t license iOS). This is a legal view.

And there is open from the network perspective. Here operators, while still in control, now are much more open to the idea of OSS and the handsets/OSes they support; even for “unsupported” devices that pop up on their network and cause them headaches. The beneficiary is the user/subscriber. This is a subscriber view.

Openness do have implications on fragmentation, but this is the topic of a different blog.

ceo

On hardware vs. software-based handset differentiation

Posted on by

Is mobile handset differentiation based on hardware coming to an end?

Back in 2007 I wrote a piece on my blog titled: The future of handset design: from hardware to software. And today this is getting more real (and validated) than ever.

When it comes to mobile handsets the rate of innovation introduced via hardware (HW) vs. sofware (SW) is and will be mainly on the SW side.

Differentiation, especially on common platforms (such as Android), will be primarily driven by SW, this is: Innovation on UIs and interface paradigms (on Android we can see this with the introduction of Moto Blur and HTC Sense), better applications (developer ecosystem adding lots of application that in turn adds to the usefulness of the handset), and better services (some phones will be very good at social things, while others at music, and so on). At the end it is SW what makes the handset more dynamic and useful and different.

Today is a great time for those doing R&D in the areas of Human-Computer Interactions (HCI).

Differentiation is necessary. But typically differentiation drives fragmentation. So the follow-up big question is on the fragmentation introduced by the different UI paradigms. Will applications need to be adapted to each new paradigm (i.e. as in many versions?). Yes, very likely.

Developers writing SW for the iPhone only have one paradigm to worry about. On the Android though, as expected we are seeing different UI paradigms (with related APIs) but fortunately the rest of the platform should remain consistent across manufacturers so fragmentation is hopefully localized to the UI only. For mobile Java (beyond Android) fragmentation is yet to be solved. For mobile web and widgets, the same although I am seeing a lot of noise around the JIL Widget SDK.

Fragmentation across platforms will continue. Fragmentation within a single platform shall be localized to the user interface (or the user interactions). Allowing for the UI to be redefined/reconfigured allows for incredible innovation on human to machine interactions which basically redefines the perception for a given handset. The next best thing is re-configurable software and hardware, but for that you will have to go play with platforms such as Bug Labs (which BTW is an extremely cool platform).

ceo

(Images sources: PopSci, Nokia, HTC Phones, Benzinga)

The Decline and Fall of Agile

Posted on by

A good writeup by James Shore on The Decline and Fall of Agile (James Shore blog).

Software development projects are a hard thing; not necessarily because of the software, but because people are involved.

I’ve worked on the most mature (and rigid) software development process in the world, the Space Shuttle on-board software (SEI 5), and on places where no process existed (startups). And I can safely say that because not all teams and projects are created equal, not all process should be equal. I’m not religious about any specific type of process. The best process is the one that is/can be followed. The best process is the one that works for your team/people. Processes can’t be forced-fed onto developers, Agile or not. Changing or implementing development processes can kill a project, especially if it impacts the existing “culture”. It is smart to consider a phased approach to this, for example, start by exploring/adapting some of the new concepts to current projects, vs. totally diving into it and potentially putting the project in jeopardy. Know to be flexible when implementing projects and when to stop pushing for (defer) something; developers (and anyone) can easily get distracted with process-things vs. delivering a product. Time is of essence, go-to-market your first priority. Processes are overhead.

Regardless of the process used, it is about minimizing the unknowns, and this is accomplished via proper planning (as needed for the phase of the project) and visibility, and execution and control, from charter to go-to-market.

Processes are at times, OK, most of the times, rejected by developers, mainly if forced, and especially if forced at the wrong time; note: developers are not stupid and what they want is to be given clear and achievable instructions (requirements) and to build and deliver it on a reasonable time-frame. Realize that process-wise sometimes most of the times “good enough” is OK, as long as things are delivered on time and with good quality. Be flexible and use what works for you; processes like Scrum or other are really guidelines.

I like to have initial efforts at front. I like to have initial planning that allows for “good enough estimates” on time-frames and budgets early on, and then I like to go iterative with cycles or sprints that allows for quick visibility and adjustments as needed, adapting in length based on where we are in the project, and team’s needs. Same on the design, I like to have an initial take at the architecture and design that will help with planning and projections and that provides a foundation for what is to come. Then we go iterative, incremental on lower design and implementation cycles that can be revisited, adapted, delivered, better understood.

The role of the product manager who owns/defines the product, manages priorities and the expectations and communication, who keeps the work plan up to date and manages scope, change, and risk at all times (control and execution) and who works well with the development team is key to the success of any software project. Then there is the development team, who are the stars who actually make things happen. Everyone must be accountable for deliverables and quality. And it does help to have smart, passionate and capable team and developers with code good coding practices and who understand what (good) software engineering, design and development is all about, and a management team who understands that writing software is a dynamic endeavor.

ceo