Revisiting the Conway Law


 This is a cross-post from my new blog "unRelated". 

The Conway Law seems to be getting a renewed interest lately. In 1968, Mel Conway, then, a manager of peripheral systems research at Univac, devised:

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

This seminal paper is definitely worth a careful read. Mel's predicates are so visionary that we could easily believe that our ability to create complex systems has not improved in over half a century.

That being said, it might be timely to ask whether the boundaries of the Conway Law are still valid and if its context has changed. 

Insight Before Communication


Leadership tends to focus on the culture and structure of an organization to drive towards desired business outcomes with the expectation is that a better culture and enhanced structure will lead to an effective communication. Actually we are so desperate in our quest to find a better culture that some people go as far as suggesting that "stealing" (ideas) become socially acceptable.

It is interesting to see that in the process nearly everyone rounds off insight, often assuming a perfect ability to gain the correct level of insight into a system design or a question. Mel touches that topic slightly before focusing exclusively on the relation between communication channels and the structural aspects of an organization:

It is a natural temptation of the initial designer to delegate tasks when the apparent complexity of the system approaches his limits of comprehension. This is the turning point in the course of the design. Either he struggles to reduce the system to comprehensibility and wins, or else, he loses control.

I understand that culturally, anyone who questions his or her insight, let alone someone else's insight, will pay a high price for it. We often cover up a deficit of insight as a mere communication disconnect as everyone seeks to appear intellectually sufficient. Mel's predicate is both foundational and consequential because it anchors our perception that insight can't be elaborated and somehow, like knowledge, directly correlates with power. That thought is pervasive in modern organizations where the Sinofskys of the world strive as long as their levels of comprehension and control enables the organization to deliver something. I find it fascinating that 50 years apart, Mel was searching to answer the question "How Do Committees Invent?" and the prevalent culture in corporations like Microsoft or Apple abhors the "Design by Committee" process.

Can we still afford to round off insight? How and what can we really communicate without the proper insight? Don't we spend way more time communicating our insight rather than elaborating it? How many companies fail to benefit from the collective intelligence of their organization?

The Context of Design has Changed Significantly


I don't want to appear condescending to an era of incredible achievements but systems do evolve and new kinds of systems require new levels of insight to elaborate proper designs. Back then, most innovations were product centric. From the mid 80s and well into the late 2000s, innovation became service oriented, and today we are rapidly moving towards an "activity oriented" innovation model.


fig 1. From products, to services to activities

In a product-oriented world, consumers are left to compose individual products to create higher value use cases. In a service-oriented world, businesses identify some of these high value combinations and deliver them "as-a-service" to their customers. The advent of Mobile platforms makes it now possible to design systems that integrate readily with the activities customers are trying to accomplish.

In an activity oriented world, the "edges" of a system take on a disproportionate importance in the design compared to their relative sizes. The focus is no longer on systems and subsystems or even their orchestration into valuable services. The focus is now on understanding every activity customers are trying to accomplish and delivering a set of products and services that will directly integrate with these activities. The design of that integration, that edge, could be, actually, will pretty much always be, far more complex than the design of products and services that support them. You don't design "User Experience" as you design systems from subsystems. Designs need to start from the appreciation of the point of view of the end user, not just from the perceived value of a service or a product.

That change is profound because the design of an edge requires all constituents to cooperate and depart from the unidimensional mindset of product and service centric organizations. Any inefficiency in the scope or variety of edges will have a huge impact on the success or failure of the overall design. In an activity-oriented world, the ability to harness the collective intelligence of your organization directly correlates to your success.

This evolution towards more integrated systems has lead to the emergence of a new homomorphism between the type of insight different groups of people can elaborate and the structure of their organization. Even the very structure of our education system and hence hiring policies are now driven by that homomorphism.

It may not have been true when Mel wrote his paper, but today it is all too common for a group to formulate requirements based their insight to drive the design of other teams. As this new homomorphism developed  the relationship between systems and subsystems, as well as the relationships between products, services and activities made it nearly impossible to devise a structure that would nurture an appropriate level of communication with the goal of achieving a shared understanding.


fig 2. From insight to shared insight

As the levels of shared or aligned insight decrease so does the ability to create compelling and sound designs. Insight gaps develop as organizations tend to focus on building what they can understand as a subset of what their leaders can comprehend. Worst of all, some elements of the design can be built undetected until they fail their organization entirely.

A deficit of insight can be so costly to an organization and its shareholders that it should be accounted for in its balance sheet.

The Tools we Use to Communicate Impact Designs Negatively


The tools we commonly use to communicate would certainly influence Mel's conclusions. Popular knowledge tools (office suite, mind maps, requirements management solution ...) allow us to express ourselves with a greater productivity, but they may also hamper communication much more than we think. Why? The very structure that we use to communicate interferes with our ability to elaborate insight and ultimately designs.

For instance mind maps assume a hierarchical set of relationships, this is unfortunate because most of the relationships in the physical world are not hierarchical. That view seems to be directly inherited from Mel's era where we could still design products in terms of systems and subsystems. Similarly, when we use some "slide-ware" every system looks like a set of layers and when we use "row-ware" such as Excel or any Requirements Management tool to capture and communicate requirements, we cannot effectively represent dependencies, let alone track the elements of the design impacted by these requirements. These artificial knowledge structures are biased and negatively impact our ability to design a system.

Probably, the most important issue introduced by knowledge tools is that none of views that we create are representing any kind of dynamic behavior. How can we create an effective shared understanding between such a wide spectrum of people when everything that we communicate is using the wrong kinds of relationships and lacking even the most elementary dynamic view? Especially when we consider that human languages are poorly equipped to communicate relationships and dynamic behaviors.

A Call for Action


We must consider Insight and Communication separately. Mel's proposition looks attractive:

Research which leads to techniques permitting more efficient communication among designers will play an extremely important role in the technology of system management.

Yet, research that would lead to techniques permitting a more efficient elaboration of insight would have a far greater impact on the system designs.

Organizations should value teams that excel at elaborating insight. This is where education and HR policies should focus.

We have to collectively drive towards closing any insight gap and expand our shared understanding to a level that is compatible with success.

We need new tools and approaches that enhance our ability to elaborate insight.

The path to insight is not as hard as it looks, from federating intuition, to developing perception to growing appreciation and ultimately formulating the vision. Never again, should an individual feel that a group is limiting the design of a system. Never again, should the design of a system be limited by an individual. Never again, should a design reflect only a fraction of the insight of the overall group of designers.


My Favorite Quotes from Mel's Article

there's never enough time to do something right, but there's always enough time to do it over.

there is a homomorphism from the linear graph of a system to the linear graph of its design organization the realization by the initial designers that the system will be large, together with certain pressures in their organization, make irresistible the temptation to assign too many people to a design effort

One fallacy behind [the Accounting theory of management] is the property of linearity which says that two men working for a year or one hundred men working for a week (at the same hourly cost per man) are resources of equal value.

As long as the manager's prestige and power are tied to the size of his budget, he will be motivated to expand his organization.

Probably the greatest single common factor behind many poorly designed systems now in existence has been the availability of a design organization in need of work.

Elementary probability theory tells us that the number of possible communication paths in an organization is approximately half the square of the number of people in the organization. Even in a moderately small organization it becomes necessary to restrict communication in order that people can get some "work" done.

To the extent that organizational protocol restricts communication along lines of command, the communication structure of an organization will resemble its administrative structure. This is one reason why military-style organizations design systems which look like their organization charts.

Research which leads to techniques permitting more efficient communication among designers will play an extremely important role in the technology of system management.

the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise. Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist. Therefore, there is no such thing as a design group which is both organized and unbiased. Every time a delegation is made and somebody's scope of inquiry is narrowed, the class of design alternatives which can be effectively pursued is also narrowed.

Coordination among task groups, although it appears to lower the productivity of the individual in the small group, provides the only possibility that the separate task groups will be able to consolidate their efforts into a unified system design.

It might conceivably reorganize upon discovery of a new, and obviously superior, design concept; but such an appearance of uncertainty is unflattering, and the very act of voluntarily abandoning a creation is painful and expensive.

We have some exciting news to report on Canappi's mobile back-end capabilities. We have used MongoLab MongoDB's hosted service for a number of projects and we have made it even easier to create data services for mobile apps using MongoLab.

All you have to do is create a data model such as that one (A job application data model ): 


Canappi generates a new MDSL file which contains 800 lines of a mobile application which can List, Detail, Create, Update and Delete any of the entities of the data model. Before you would have had to write these 800 lines by hand pretty much:

And voila, you can generate the Objective-C code for the corresponding iPhone / iPad application, including the login screen for the entities that require login (do not forget to create a hireme database in MongoLab and update the API key):

And ... well if you wanted to deploy your app using PHP/MySQL or WSO2 Data Services Server, the same data model definition enables you to do just that !

Canappi is well positioned to help you create dual-resolution, dual factor, dual platforms apps. We already supported dual screen resolution for the iPhone / iPad Universal Binary model. We just released today an update to our Eclipse plugin and code generator that fully supports programmatically iPhone 5 screen resolutions. We extended our coordinate system to model a shift that is applied to the current coordinates when the app is running on an iPhone 5.

text name (10,60,100,30 + 0,10,0,2) { ... }

This means that the name textfield will be displayed at (x=10,y=60) on iPhone 4 (with a width of 100 and height of 30).  On the iPhone 5 it will be displayed at x=12, y=70 with the same width and a height 32.

With that approach you can even bring "off screen" controls within the view bounds when the view is displayed on an iPhone 5:

text name (-200,60,100,30 + 220,10,0,2) { ... }

So this is what you do with a single MDSL file, yes, dual resolution, dual form factor and dual platform.




Retina Display

(iPhone 4)


(iPhone 5)



Retina Display


iOS yes yes yes* yes yes
Android  yes**   N/A  yes (up to 1280x720)  to be released soon  N/A

*to activate your project to work in an 4" size, you need to add a PNG file to your project named: Default-568h@2x.png. Here is a blank one you can use for testing. This file will automatically used as the 4" version splashscreen. It's hard to believe that Apple could be that clumsy, but so far this is the only way I have seen to get the app use the full 4" resolution.

**On Android we use DIP and we have experienced a really good support of various screen resolutions, from 320x480 to 1280x720, using a positioning space of 320x480, in other words, in DIP mode, Android adapts the positions and sizes of the controls defined using a coordinate system of 320x480 to fit well the current resolution of the screen. This would not be true of graphic files and it is recommended to provide resources that match the phone resolutions from 320x480 to 1280x720.

What all this means is that all of our customers can rapidly migrate their applications to support all these resolutions within a single MSDL file that contains:

  • two independent layouts (one per form factor phone /table).
  • the shifts to be applied for larger screen resolutions. 

This is what the MDSL file would look like:

//A single definition file to support 8 different runtime options

layout myTabletLayout {

text name (10,60,100,30) { ... }


layout myPhoneLayout {

text name (10,60,100,30 + 0,10,0,2) { ... }

tablet myTabletLayout ;


This is a tremendous validation of our approach and programming model.

We'll be releasing support for ARC and some key function of iOS 6 with our release 1.4 early October.


Mobile App Monetization

David Barnard wrote a really interesting post on the recent acquisition of Sparrow. This is a must read for any mobile developer expecting to make a living from their craft. This could actually very well be the best article written on the topic.

But I want to warn people against his conclusion. I think there are two elements of his rationale that are flawed.  He wrote back in 2009:

unrealistic pricing expectations [...] may haunt the entire mobile software industry for years to come

And added today:

In hindsight, I think “haunt” was the wrong word to use. Though it wouldn’t fit quite as well semantically, or be quite as provocative, I think the right word to use there is “change”.

The reality is that Apple successfully delivered a monetization platform, this is actually one of the most fundamental change introduced by mobility (with location). Not so much because developers can -now- potentially be free from the -bait- model the Web introduced where the end-user "is-the-product", but because now commerce can be delivered in a fundamentally different way. An app is just an agent of commerce not the object of commerce

The Web never ever changed how commerce was done. e-Commerce was commerce and is still commerce 20 years later, you still take this bit of plastic out of your wallet, and you still establish a one to many relationship between yourself and a bunch of people. Even in other areas such as outsourcing, the Web didn't change much, call centers existed before the Web, they simply moved. The Web just abstracted (a bit) location, but for all intend and purposes the Web didn't change a single thing to the way commerce was done.  It might have gave you the illusion, that's all.

What The Platform is changing fundamentally is that it introduces a mediator in the commerce relationship, a One-to-One-to-Many relationship, actually it is even more complex than that, it introduces a One(end-user)-to-Many(apps)-to-One(platform)-to-Many(merchants, service providers). It does that in a relatively secure and private way allowing financial transactions to flow between all these actors. 

Claiming that you can't make a living because a single business model (selling apps on the app store) doesn't seem to bring in enough income is at best short sighted. I can come up with at least 10 transaction models (exclusing ads which transformed the web into a zoo) that will help developers and service providers monetize their relationship to end-users.

Just this morning I stumbled upon this eBook that the French newspaper Le Monde just published. It was written on iBook Author, one of the most amazing "app" I have seen in a long time. And all the sudden everything became clear, this was the business model the press was waiting for: news has become a commodity, nobody wants to pay for news. Social network have forever disrupted the relationship between newspapers and their readers. But ... at roughly $5, lots of people might pay for the analysis behind the news, the broad perspective that the journalists can provide because they follow astutely "the news". And yes, in case you have not noticed, in a fairly incredible turn of events, turning the entire model of the press on its head, the "news" becomes the ad that would lead to customers buying the eBook. What better ad, than a piece of news that will drive people wanting to know more, wanting to understand deeper perspectives well beyond the news?

The second flaw in David's rational is the "one-size-fits-all" mentality of app developers. This is a major flaw, again inherited from a very old age, when you could not address a billion potential customers. This is what "The Platform" changes, unlike the Web, which at best allowed one person to buy stuff and services from a remote places, the platform turns the entire commerce model on its head. It allows anyone including David to sell into a one+ billion user market. Do you really think that "one app" can appeal to 1B users? Angry Birds, anyone? Isn't it time to rethink what software is? Don't you think that a) if you are lucky, one app would only resonate with a small subset of this billion users and b) if you are not, you may never find your market, when in reality a different set of features organized in a family of apps could have found many  "puddles" of 10-20 million users? Take any of David's apps, don't you see how they could be organized into a family of apps that could appeal to many different market segments, geographies, ... even price could be different. Some users might be paying $20 for a premium app, other would never pay more than $.99 for a couple of features, but maybe that's a 100 million puddle.

For the last 20 years our economy has been trained  to standardize products and to perform binary commerce transactions. I don't know the future, all I know is that people who will not think out of the box page and people who will not try to understand the tectonic shift introduced by the Platform will come to the wrong conclusions. In essence, the only thing these people are telling us, is that BAU (Business As Usual) is dead because it does not work on the platform. 

Of my entire career, nothing has been more dramatic and transformational than when Steve Jobs returned to Apple in 1997 and shelved NeXTStep. All my dreams, all I had worked for, for 10 years, were shelved as well. By then, companies like GM, Hughes, Samsung, NTT, Siemens, EADS (Aéropsatiale back then), Essilor, lots of research labs in Europe, ... were using my software doing great things with it and somehow, this was shattered in one instant. Believe me, when people complained they could not upgrade their Lumia 900 to Windows 8, they are not even 100 miles close to the pain you get when you see a full decade's worth of work go away as your technology platform vanishes before your eyes. To a certain degree I think we have all lived this kind of event, not as instant and comprehensive as the NeXTStep one. Even Flash gave a 5 year warning to its developers. 

With that in mind, I was amused to see this Mobile Development Platforms Gartner Quadrant this morning. A friend of mine asked me what did I think of it? What is a sensible no-bs lasting mobile strategy  in 2012? I didn't see the Web Platform Magic Quadrant CIRCA 1995, but I bet it was not much different. Tiny (NeXTStep-based) WebObjects was the leader then... how many iterations have we been through? who could have predicted the rise of PHP? where are we now? All we know is hype always got it wrong, despite all the might of a Gartner or an IBM or Microsoft, completely wrong. "What works" wins. Always. So here is my answer:

1. Create your picture of the device market

We are at the last stop before this market is completely locked in by Apple and Google. I wrote that piece a couple months ago explaining that unless Microsoft somehow associates itself strongly with Facebook, Nokia and HP and adopts a vertical strategy, there will be no Microsoft in the mobile space moving forward. Today we know for sure the device market will be at most a three platform game and, after watching Google I/O's Keynote, my bet is that it will be just two platforms. Anyone who is trying to convince you otherwise simply doesn't understand that a device that runs an app can no longer exist without a platform behind it. If Sony, RIM or even Amazon do not have a sustainable platform behind their devices, nobody will buy them. It's funny how people can't grasp the "form factor" of software: they see a device, they think this little thing is autonomous, doesn't rely on something other than a voice and data connection, they don't see the extend of the software component behind. If they somehow could visualize some of their systems with a physical representation, I bet our industry would look much different. For instance this is a picture of the Nokia Lumis 900 after Microsoft's annoucement last week and here is a "Kindle" for instance (albeit not as pretty, I mean the Kindle is not as pretty as this public bench):

2. Understand that writing software for mobile devices is unlike like writing software for desktop

I would recommend a couple of presentations:

a) 6 Design Rules to Design Amazing Apps

b) Building Mobile Applications That Rock

c) The mobile user experience

I would also recommend you understand where you fit and how you plan to use the mobile ecosystem. Here is a map that can help you:

3. Native vs Web?

Except for the people that make a living off Web technologies or the ones that are emotionally attached to the Web as a platform, everybody will tell you that HTML5 is not there yet and most likely will take at least a couple of years before it can catch up with native technologies, if ever. Just ask yourself how many Web apps do you actually use on your own smartphone? zero? Why don't you also ask, of all the native apps that you use, which one would be better as a "Web app"? zero? Users choose the best UX, period, technology is the least important factor in their choice. I mean come on, after nearly 20 years of evolution who can tell me that even on the desktop there is a Web app they would still use if they had a native choice? Everything that the Web was not, Apple baked it in its platform and won. Maybe the industry could stop for a second and ask why? If you still don't believe me, please watch this presentation. Even Facebook finally gave up ... 

Not only Mobile Web frameworks don't work well in all the devices browser (contrary what the vendors say...), but you'll still have to deal with pixel level precision across multiple device form factors, they don't do that, not even close. Do yourself a favor, try building a small sample app (3-5 views with an API call) in iOS, Android and jQuery mobile, and try to run it on 5 common devices and let's talk again. Just for fun, just embed a call to a mobile Web page within one of your WebView and compare the user experience with the corresponding native view. Yes, as Google pointed out in its keynote the human eye can detect up to 10 ms delays. Even a ping can't be done in 10 ms.

If you want to take advantage of all the latest device capabilities do you think native or Web technologies will give you the best access? If you want to save bandwidth, power and deliver the best user experience, which app will do that? Native or Web?

Do you have an Android device? What do you think of the Google Weather App? yes, when you ask for the forecast and you are redirected to a "mobile-optimized" web page that displays the weather forecast in your city. Do you think you want your users to go throught the same kind of experience? Yeah, I guess you get my point. 

Don't be fooled by Web developers who see the train coming (or going) and they are either going to be steamrolled by it, (or simply stay on the Web platform, so to speak).

So, with 2 platforms to support, it is actually fairly easy to build a mobile team that will be proficient in both. Beware of people scaring you with the wrong problems to buy their tools. The only problem you have, the only question you should answer is how do I deliver the best user experience in the context in which the app is used for the devices that my end users have. Everything else is a waste of time, because we are now in an End-User driven market, geeks no longer have the luxury to chose what is convenient to them. They hate it, this is the first time in history they lost control of their technology choices, but they are going to have to learn to live with it if they want to tap the 1+ billion user smartphone market. That's actually very refreshing. End-users expect certain patterns and behaviors, these patterns and behaviors are all native. One of them is actually quite interesting: End-Users expect to spend money to buy native apps... 

4. Middleware

You would think by now that most companies will have developped some kind of allergy to proprietary/closed middleware platforms (or at least an immunisation mechanism). It is already bad enough to be locked in Apple and Google, imagine being locked in a much smaller vendor who can disappear, change direction or be acquired any minute. Yep, that's the value proposition of companies like Rhomobile (now SAP) or Antenna: support all the platforms you don't need while you get locked in ours. Even IBM would have never thought of this ... wait actually they did. They bought WorkLight for 70 M.

Why don't you ask them how fast they are going to be following evolutions of Apple and Android SDKs and how low the common denominator  in supporting every platform is going to be?

5. Keep it Simple

In the light of this context:

  • Rapidly evolving technologies and devices
  • Quasi certain dominance of 2, likely, or 3 vendors at most
  • UX being the prime factor of the success of an app
  • Pixel level precision GUIs
  • The Platform beneath
  • Subpar Web technologies

If Instagram can teach us something (other than printing money) is that Content is now produced, delivered and consumed in a completely different way: in context. The browser is dead, long live HTTP. Everything is on the table to be reinvented. 

My recommendation is keep your strategy as simple as possible: write your apps for iOS and Android. This is not the end of the world, it is relatively easy to hire a small team of polyglot developers. You don't need no middleware for that. Before you know it you would have spent millions of dollars for capturing just a few % of the device market or supposedly empower your developers to write apps in ... two platforms. Who in their right mind would spend that kind of money? Where is the business case? Just buy an iPhone or an Android phone for your employees who use any other device. That will be much cheaper than any middleware or developing for additional platforms.

Gartner will always be Gartner, they make lots of money selling these Magic Quadrants to both ... the vendors and their "customers". So you have to decide whether you want to be scared by that picture or leap-frog it with a Simple (but far from simplistic) Mobile Strategy. Your call ...

Post Scriptum: Mobile Web Sites

Yes, mobile Web sites are not going away. And HTML5 is a good fit for them. But you have to think in terms of form factors: understand that "search" has become an "app", a family of apps. You search in context, Yelp, UrbanSpoon, Fandango... on a mobile device, you rarely search out of the blue or research some information for your homework or paper. You search for a purpose and there is a search app for every purpose you can think of. Search might even be considered just a feature, not even a family of apps. So think of your mobile Web site as being a way to publish information to a small search app that people use now and then and that app is called Google. Again, think in terms of form factors. The Web form factor in a mobile world is this tiny island of HTML rounded up by a -plain vanilla- contexless search app. So all you really need is a couple of "Web" pages so people can find you if they care to look. Make sure you provide a link to your native apps on these pages. That's all your users care about. The Web is emphatically tethered. Make no mistake about ot. 


Mobile Diet Update

I reached another milestone today. I now lost 40 lbs in the last 6 months. I just got under the 200 lbs mark (90kg). The rate of weight loss has slowed down just a tiny bit, but that would be expected. I am expecting to lose another 20 lbs or so.

The graph below represents about one year worth of data. I must admit that I could never imgagine I would be at that weight today. This kind of thing looked impossible.

My blood pressure is back to nearly normal, away from levels considered dangerous.

I did some blood test and my cholesterol was down 50 %, yes 50%.

I cannot emphasize enough that if I can do it, anyone can do it. Losing weight is actually easy unlike what an industry would like you to beleive.

<< 1 2 3 4 5 6 7 8 9 10 11 12 ... 22 >>



blog engine