Big development teams working on big projects believe in formal design and thorough modeling. Small teams working on small projects don’t model their projects, and they look at design as a casual part of the software development life cycle.

Does that oversimplify the role of modeling and design? Of course. But there’s a lot of truth, and for the past two decades, modeling and design have become more sophisticated but haven’t made inroads into the bulk of enterprise software development.

Modeling is ubiquitous when designing passenger aircraft or high-speed financial trading applications—huge, expensive projects where the cost of failure is prohibitive, and where it’s worth taking the time to do all the up-front work using UML-based modeling tools. In that world, designers complete their work long before programmers fire up their IDEs. And that’s the way it should be.

When creating your most recent Web application, or when crafting an integration between two silos, did your organization do modeling? If so, did it use the power and scope of UML2, or just fill up a whiteboard with some basic flow diagrams? If you modeled, good for you. If you didn’t, don’t feel bad; modeling is often seen as not worth the time and expense. Worse, formal design seems antithetical to the fundamental tenets of agile software development.

Formal design doesn’t have to be big, expensive and monolithic. Design and modeling can be quite synergistic even with the most agile methodologies. So why aren’t they used? Because modeling isn’t well understood, except as something that “big shops” do. Because modeling languages, like UML2, are too complex; they’re comprehensive, but are hard to learn and to use. And because most modeling and design tools are geared for the high-end market and are overkill for today’s small, distributed and nimble development organizations.

Maybe the solution lies in non-standard modeling environments, such as those used by Microsoft’s Visual Studio. Maybe we’ll find a simpler, more usable answer when UML3 appears in a few years. But we think that the real challenge isn’t in tools—it’s in attitude. Let’s all stop talking about how modeling designed jet fighters. Unless development managers hear positive stories about how modeling helps more modest applications, it’s never going to win the hearts and minds of today’s trigger-happy code-slingers.

We pay for Apple secrecy
When Apple’s prototype smartphone is lost in a Silicon Valley watering hole, it becomes front-page news in the New York Times and the BBC. Can you imagine that happening to any other company? A prototype Dell laptop? An in-house alpha of Windows 7? A next-generation Motorola flip-phone?

Apple is famous for controlling its message—and for silently insisting that it knows better than its customers. No Blu-ray disc capability on the Mac? You don’t need it, says Steve Jobs. What about using third-party application frameworks to simplify writing mobile apps? You don’t want it, says Apple, because programs written with those tools don’t run well. (And then the company’s license agreement prohibits the use of such frameworks.) Because Apple controls the only official means of distributing apps, it’s either Apple’s way or the highway.

Apple customers have been dismayed at the company’s casual arrogance and secrecy with the apparent iPhone 4 antenna problems. If you place your fingers on the wrong part of the phone, it can drop calls. What does that mean? It means you’re holding the phone wrong, says Apple. It’s not Apple’s fault; it’s your fault. Few other details are forthcoming from the House of Secrecy. The company does not see itself as accountable to its customers.

Or, apparently, to its developers. What if you’re trying to make sense out of Apple’s often arbitrary, sometimes nonsensical, and inconsistently applied restrictions on what types of apps will be allowed in the App Store? Apple sees no need to explain its license terms to developers, or to help them understand the gray areas. The Great Oz Has Spoken.

We, perhaps naively, expected better of Apple. What a disappointment.