Wednesday, April 21, 2010

My Philosophy of Architecture

The first part of being a good architect is to observe. That means listening to others, using the existing products, inspecting some of the code, or getting involved in some. Unless there is a very specific technical problem you’re faced with day one, applying you’re technical skills day one is probably a mistake.

The second part is to identify needs. A key part of an architect’s position is to identify the needs that development teams didn’t know they had. Sometimes they do know these needs, but aren’t quite willing to admit it. It’s important to be careful in how you use that information. If you run out in to the office and shout out your findings, it’s unlikely you’ll meet the future steps with much cooperation from the development teams. I have to admit, I’ve had that lesson reinforced the hard way more than once.

The truth is that while you may be correct about those needs, the damage to trust is real, and justified since it’s likely upper management will see your declaration as a critique on the competence of the development teams. It’s not impossible that your discoveries are valid criticisms of the development teams, but it’s more likely there are historical reasons behind them. Deadlines, an unpredictable shift in technology, or an encumbrance that predates their time are some of the many possible root causes.

At the same time, it’s necessary to be providing solutions to the needs the teams already know. Sometimes those questions have uncomfortable answers. For example, they may be having problems with performance due to chatty communications. The answer they are hoping for is a super compression algorithm, but no compression algorithm can fix chatty communications. An architect is responsible for more than just solutions, an architect is responsible for mentoring developers and helping them understand why solution A cannot fix their problem and how to avoid ending up in the same trap in the future.

In the other direction, toward executives, an architect’s role involves setting expectations, and building support for the needs of development. Of course as well, there is much listening involved, because an architect must use information on product plans to determine what long term needs exist in development that have not yet been identified, and to evaluate the priority of those that have. Maybe there is a need to support a different platform, or a different device. Those needs would advocate more attention paid to how the user interface and model are separated.

Setting expectations not only covers the obvious, underestimation of effort and duration, but also the highlighting those areas where changes in software or hardware have opened new opportunities.

Since it’s common for development managers to have aggressive schedules, an architect often needs to be the voice advocating for a little more time here or there to get the fundamentals right. These efforts should pay off later, but since those benefits may be outside the project itself, organizational, or just longer term, it may be counter to the incentives given to other managers.

That conflict of priorities, and how to handle it, is often a greater challenge than the technical problems themselves. It would be appealing to see what would happen if an architecture department had an allocation of some kind such that it could internally compensate development teams for the extra efforts architectural initiatives may introduce to their product cycle. In my experience though, the main credit of an architect is trust. Cultivating trust among development teams and executives, making sure executives understand the benefits to overall development architecture brings. In addition, making sure executives understand the constraints of the development teams will win you trust among the development teams.

Sunday, February 14, 2010

How the iPad (or a similar form factor device) can be successful

iPad rumors circled the Internet for more than a year before the eventual unveiling, and when finally unveiled, reactions were fairly mixed.  Most importantly, they were mixed even among the hard core Apple crowd, showing some deep flaws in the marketability of the device.

I’m not in that crowd, but I’m similarly nonplused with what was announced.  I own a Kindle and love it.  I can’t see anyway that the iPad would be an appropriate replacement for it.  It also isn’t a replacement for a laptop, and certainly not a cell phone.  No, you’re right, it doesn’t absolutely need to be a replacement for anything, but as a stand alone device, even if you gave me one for free, I can’t see many situations in which I’d choose to put it in my bag.

All that said, I don’t think it’s entirely doomed.  The problem I see is software more than hardware, though there are some areas for improvement there.  What hardware like the iPad would do well at is as an accessory, not a standalone device.  A touch sensitive screen of that size would make an excellent portable input device if the right software ecosystem existed around it for pairing it with TVs, PCs (this means Windows), music systems, etc.  Essentially what I’m saying is it could be the ultimate remote control, though thinking of it as simply a $500-$830 remote control isn’t going to give you the whole picture.

I don’t think Apple has the right ethos to pull that off.  Apple has a little too much of the “come to us and play by our rules” mentality to create an ecosystem in which a device like that would succeed.  Apple’s partnerships tend to be either very closed and locked down (AT&T, Adobe for many years) or exploiting their fan base (App Store).  Neither will work in this scenario because their fan base doesn’t make hardware.

Probably the biggest stumbling block would be the interfaces to PCs.  It doesn’t seem likely Apple would ever consciously create a PC accessory.  Sure they can do that same thing for Macs, but as an accessory it makes far more sense for desktops than for laptops.  As an accessory to a desktop it would give you a convenient input device to remotely control the PC from and get notifications.  That’s useful for AV, for communications, and for simple things.. like finding a recipe online, with a nice keyboard and monitor, then taking your pad into the kitchen.

Essentially what I’m talking about is a supersized SideShow device that not only hooks up with your PC, but with other hardware using either WiFi and/or Bluetooth.  Still not sure I’d pay $500 for such a device, but it’s certainly something you could get me hooked on pretty easy, and once you’ve done that maybe you could convince me to consolidate devices and stop using a Kindle separately, making the $500 a little more palatable.

Wednesday, November 18, 2009

XML Schema 1.0 – Extensibility

One of the great flaws of the XML Schema specification, at least 1.0, is the great number of limitations placed upon the xs:any construct. The next version, 1.1, addresses or tries to address the majority of those flaws. But 1.1 isn’t final yet, and even when it is, the number of tools that need updates insures there will be continued use of 1.0 for some time still.

I’ve seen a few workarounds (a good list) for those flaws, and no surprise, all have limitations. I have a new one. It has limitations as well, but I for most situations, I think they are less important.

xs:any allows namespace to be declared as either #any, ##other or a list consisting of ##targetNamspace or any other namespace. #any is appealing except that you’ll nearly certain to run afoul of the determinism flaws of XML Schema 1.0. ##other is also appealing, but it really only solves your V1 to V2 issues, but leaves V3 not resolved. What you really need is a list of future namespaces.

So the solution is pretty simple, pre-declare your future namespaces. Here’s an example:

   1: <xs:schema
   2:     targetNamespace=""
   3:     xmlns=""
   4:     xmlns:xs=""
   5:     elementFormDefault="qualified"
   6:     attributeFormDefault="unqualified">
   7:   <xs:complexType name="Name">
   8:     <xs:sequence>
   9:       <xs:element name="FirstName" type="xs:string" minOccurs="0"/>
  10:       <xs:element name="LastName" type="xs:stirng" minOccurs="0"/>
  11:       <xs:any minOccurs="0" maxOccurs="unbounded" 
  12:         namespace=""
  13:         processContents="skip" />
  14:     </xs:sequence>
  15:   </xs:complexType>
  16: </xs:schema>

The main difficulty with this solution is maintaining the “any”. For this purpose I have a “build” tool that among other things takes an XML schema written without the any and adds it. I’m working on an open source extensible project for that purpose called XsPub, but for various reasons it’s not very complete. Anyhow, at work I have something similar, just less extensible, and more specific to our needs (and finished ;p).

To actually make an extension you need to reference an element from the new namespace, and drop that namespace from your any.

For example:

   1: <xs:schema
   2:     targetNamespace=""
   3:     xmlns=""
   4:     xmlns:v2=""
   5:     xmlns:xs=""
   6:     elementFormDefault="qualified"
   7:     attributeFormDefault="unqualified">
   8:   <xs:import namespace="" schemaLocation="v2.xsd"/>
   9:   <xs:complexType name="Name">
  10:     <xs:sequence>
  11:       <xs:element name="FirstName" type="xs:string" minOccurs="0"/>
  12:       <xs:element name="LastName" type="xs:stirng" minOccurs="0"/>
  13:       <xs:element ref="v2:MiddleName" minOccurs="0"/>
  14:       <xs:any minOccurs="0" maxOccurs="unbounded" 
  15:         namespace=""
  16:         processContents="skip" />
  17:     </xs:sequence>
  18:   </xs:complexType>
  19: </xs:schema>

And the declaration of the element in the v2 namespace.

   1: <xs:schema 
   2:     targetNamespace="" 
   3:     xmlns=""  
   4:     xmlns:xs=""
   5:     elementFormDefault="qualified" 
   6:     attributeFormDefault="unqualified">
   7:   <xsd:element name="MiddleName" type="xs:string"/>
   8: </xs:schema>

The result is a set of schemas, v1 and v2 that both match the below xml document, but for which v2 understands the added content.

   1: <Name xmlns="" xmlns:v2="">
   2:   <FirstName>John</FirstName>
   3:   <LastName>Doe<LastName>
   4:   <v2:MiddleName>Richard</v2:MiddleName>
   5: </Name>  


Wednesday, November 11, 2009

US EPA Big Polluters

Heard of the decision by the EPA to classify CO2 and other greenhouse gasses as pollutants, and regulate them?  Whether you have or not, here’s are three other things you should know.  First that first finding was supported in no small part by the 2,000 that gathered in Seattle outside the EPA hearing on that topic.  Second, the EPA is proposing to move forward to the next step, actual regulation, starting with the “big polluters”, that is, new or modified sources of 25,000 tons or more of CO2 or equivalent emissions. Third, just like with the endangerment finding, the EPA is holding two public hearings, and one of them is next week here in Chicago.

This is an important event for climate change politics, and you like the 2,000 that gathered in Seattle can play a pivotal role.  The Sierra Club is organizing supporters and we would love to see you there.  There are two ways you can help. 

First you can attend and testify, telling the EPA that you support the rulemaking.  You don’t need to be a climate scientist, the EPA wants to hear from the public.  In addition, Sierra Club will have a room at the hearing where you can stop by to learn more and get help preparing your testimony. 

If you don’t testify, attending is still awesome.  Pick up a sticker, listen to others, and show your support.

Last but not least, spread the word.

Sierra Club Flyer -

Sunday, July 19, 2009

Software Engineering, Control, Measurement and Trust

There is much clamor over this article, “Software Engineering, an idea whose time has come and gone?”, by Tom Demarco.  I love it.  At work, I know a manager who has the tag line “You can’t control what you can’t measure” posted on his office door.  It’s always given me the heebie-jeebies.  Tom hits one of the main points right on the head, that it implies “that control is an important aspect, maybe the most important, of any software project”,  But as Tom admits, “it isn’t.”

The other half is the how it plays together with the the "What isn't easily measurable, doesn't exist" rule.  Tom sees this too, and describes it like this:

“Now  apply  “You  can’t  control  what you can’t measure”  to  the  teenager. Most things  that  really matter—honor, dignity, discipline,  personality,  grace  under  pressure,  values,  ethics,  resourcefulness,  loyalty, humor, kindness—aren’t measurable. You must steer your child as best you can without much metric  feedback.”

I don’t fully agree with his prescription, to require the product team to be ready to ship in any given week of development.  Like the original guidance, there is a kernel of truth here, but an overreaching of application.  There are many good reasons to pursue a “ready to ship” strategy, but you need to be flexible.  You need to accept that there are some tasks that will break that goal.  You cannot replace important subsystems without causing at least a bump, and sometimes you need to do that. 

If you have the goal in place, but are flexible, then you can create a branch, do most of the work there, and once it reaches a certain level of maturity (no longer experimental), integrate.  Integration will cause some pain, on both sides, and you have to balance between disruption to the mainline team, and your ready to ship goal, and the probability that if you insist on zero mainline pain that the branch may never merge.

But anyhow, though it sounds like a prescription, Tom says it’s an example, and as an example it’s perfectly valid.

Like raising a teenager, when you have important things, that aren’t easy to measure, what you need is trust.  You need to be able to trust that your team understands your motivations, your goals.  They need to be able to trust that you will treat them fairly if they help achieve those goals.  A ready to ship strategy is just an example of “don’t do anything too crazy”.  It can help build trust because management can visibly see progress, and because hopefully when management sees that they say “thank you”.