Showing posts from November, 2009

Where portability matters

What's a good example of a software solution where portability is a paramount design quality attribute? Tethering software for mobile phones. PDANet, an application developed by June Fabrics, is a good example where designing for portability is a top design concern.
Portability is defined as the ability of a system to run under different computing environments. The environment types can be either hardware or software, but is usually a combination of the two. (Definition source)
PDANet enables PDA owners to convert their device into an Internet connection. It's hard to say if the talented folks at the June Fabrics initially planned to expand their PDANet software to other mobile OS vendors, but this application is a prime example where portability matters.
Currently PDANet supports Android, Palm OS, Windows Mobile, BlackBerry, and iPhone. While the operating systems are fundamentally different and provide different level of services to developers, the architectural drivers (i.e. …

Impact of organizational politics on software design

What is the impact of organizational politics on software design? This is a question I raised three years ago in this post and the time has finally come to attempt to answer that question.
We, as software solution stakeholders, make conscious and subconscious decisions that have a profound long-term effect on the usability, maintainability, cost, security, implementability, any-ility of a software solution. But how often are these decisions based on our personal and career motivations? Are we aware of this? Is it a good or a bad thing? If my career is centered around a certain vendor (e.g. Oracle and Java) should I or even can I viably consider technology from other vendors (e.g. SQL Server and .NET)? Would I have enough technical knowledge?
If you have an immediate thought on the impact of organizational politics on software design please leave a comment. And look for a formal invitation to fill out a survey in the very near future.
Constantin K.
Firebrand Architect®

Essays by Paul Graham

Paul Graham is an essayist, programmer, and programming language designer. If you haven't read his essays on programming and software engineering you should consider.
His latest essay on Apple's iPhone store is a good read on how business models that work for product n may not work for a product y. In this case Apple is treating iPhone apps as if they were iTunes songs, and Apple being the broker between the consumer and software producer. The nature of the development process of the iPhone apps requires frequent, if not daily, iteration of software releases, while Apple favors a lengthy review cycle before an app is published in its stores. What will it take for the developers to switch platforms? When will Apple become the evil empire? You can find the latest essay here and the rest of the essays here.
Subscribe to this blog via RSS.
Constantin K.
Firebrand Architect®

Pricing Software

We're in the business of software. That's why we all care, directly or indirectly about its pricing. Pricing affects everything - our salaries, benefits, profit. We also care about pricing because we're all are buyers of software (COTS, GOTS, development tools, etc.). And of course with respect to computer systems the cost of software exponentially outweighs the cost of hardware.
The new book, Don't Just Roll The Dice - A usefully short guide to software pricing, is a quick read, mere 84 pages, raises the right questions to get you thinking.
"How do you price your software? Is it art, science or magic? How much attention should you pay to your competitors? This short handbook will provide you with the theory, practical advice and case studies you need to stop yourself from reaching for the dice." Download a free copy here or get an a physical copy from Amazon.
Constantin K.
Firebrand Architect®

Software engineers are also your solution architecture stakeholders

It's easy to forget that the software engineers on your development team are also your stakeholders. They need a particular view of solution architecture in order to understand how they fit into the development ecosystem.
Expect to be challenged. As you walk through your vision or proposal for how a solution should be analyzed and architected be prepared to field questions from developers. More importantly, be prepared to answer those questions from developer’s point of view using terminology and analogies they understand. Since software architecture concepts deal with systemic issues of a software solution that extend beyond the routine scope of a software developer, be prepared to also educate developers on why it’s important to evaluate and address crosscutting solutions needs. You’ll have to demonstrate why a software architecture centric view is necessary and why a given approach (e.g. concentrating on architectural drivers early on) best suits a given situation. And of cours…

Need experience planning for and executing a long term project? Run a marathon.

This thought came to me on mile 21 of the Marine Corps Marathon that I ran and finished on October 29th, 2009. Planning, training for, and running a marathon is similar to executing a long term successful project. Both activities require superior commitment, strategic planning, progressive results, and a clear goal.

A marathon is different by definition - it's a solo event. However there are some points of interest.

- Goal. For a marathoner a goal is clear - finish the race in a given time period. A successful project must have a clearly defined goal that can be achieved and measured.
- Planning. Superficially it may seem that planning for training is easy. However poor planning will prevent you from training properly. And you won't be able to catch-up later (an equivalent of Fred Brook's motto of adding more people to a project that's already late will only delay a project). Long runs must be planned - including a day before and runs during the week. Planning for a long…