Archive for the 'System Design' Category

25
May
10

Glenn Gruber: The Fallacy of Software Factories and the Importance of Talent

Glenn Gruber: The Fallacy of Software Factories and the Importance of Talent

Mr. Gruber makes a number of good points in this post regarding the general tendency in IT to try to commoditize talent within the software development space. While we at Delivered Innovation employ a “factory approach” to development, our philosophy regards the standardization of the delivery process itself, and not the application of tacit knowledge to the process of creating value, as the ultimate candidate for standardization. Glenn is spot on in his assessment that many firms within the outsourcing world try and apply a factory model for the purpose of reducing development expertise to the least common denominator, and this comes at the expense of quality design…and ultimately of quality output.  DI has been brought on to a number of large “cleanup” projects in the Force.com space this year to untangle messes created by these so-called software factories where developers are routinely referred to as “bodies” (as in, “We’re behind schedule, so let’s throw a few more bodies at this”), and in every case the customer ended up spending significantly more on the project using resources that may have cost less on a per-hour basis, but ended up costing more in the long run due to the watered-down skill levels and lack of insight into the big picture design and architecture.

Three key points:

…under the traditional outsourcing model success (i.e. margins) is achieved by trying to break any task down into its most basic components so that those activities can be completed by the most junior and cheapest resources.

Tools and methodologies are more like guiderails to reduce mistakes and help less-seasoned developers accomplish more advanced tasks, but don’t necessarily guarantee well written, high-performance software.

Architecting, designing, building and testing products that are tied to revenue, that require high levels of performance, scalability and resiliency is not a task to be done by lowest-common-denominator individuals.

09
Apr
10

Book Preview: The Design of Design by Frederick P Brooks Jr.

Delivered Innovation has been given the opportunity to read a chapter excerpt and do an early review of Frederick P. Brooks, Jr.’s new book  The Design of Design: Essays From a Computer Scientist. Brooks is most renowned for his book The Mythical Man-Month. In The Design of Design, Brooks explores of the process of design, focusing equally on the creative and technical aspects of design as well as the bureaucratic, hierarchical, and political interactive. In other words, how can a design process best incorporate (and nurture) the artfulness of design while not compromising the real time needs of the project?
Chapter 6 is entitled “Collaboration in Design.” He begins with the observation:

Most great works have been made by one mind. The exceptions have been made by two minds. And two is indeed a magic number for collaborations; marriage was a brilliant invention and has a lot to be said for it, but notes that, while single or double-minded design works best as a result of the single-minded purpose of design, the practice of team design is absolutely necessary because of, the increasing sophistication of every aspect of engineering… I am impressed that there are no naive technologies left in modern practice.

Brooks explores the drawbacks of collaboration and the ways to take advantage of and manage collaboration, but the section that grabbed our attention most was his key to successful collaborative design – the System Architect.

[The Sytem Architect] must have a clear vision of and for the system and must really care about its conceptual integrity… Only the architect represents the users. And, for complex systems as well as for simple residences, it is the architect who must bring professional technology mastery to bear for the users’ overall, long-run interest. The role is
challenging.

Being in the business of cloud Architecture, we couldn’t agree more. We oversee different design teams and steer their output towards an outcome that MUST please the user, i.e. our client. The challenge is the mixture of expertise with the skills of management while meeting the needs of the client (and sometimes defining the vague or moving needs for the client). Brooks nails it on the head and his incorporation of dry humor into a clear layout of a complex subject appeals to us. We’re looking forward to the rest of the book.

Check out an excerpt from The Design of Design here: The Design of Design Chapter Excerpt (101)




Cloud computing application & service design by Delivered Innovation

Subscribe to Delivered Innovation with RSS  Follow Delivered Innovation on Twitter  Find Delivered Innovation on Facebook