Comments for The Responsible Designer

Comment on Little things add up by Who is Rebecca Wirfs-brock | Yves Hanoulle

Who is Rebecca Wirfs-brock | Yves Hanoulle — Tue, 27 Sep 2011 18:39:59 +0000

[...] I know it was when I was learning OO. When I was doing more and more agile stuff, I noticed that she now wrote articles about TDD. Today in the agile community we have a lot of people who don’t have a technical [...]

Comment on An Architect’s Dilemna: Should I Rework or Exploit Legacy Architecture? by Rebecca

Rebecca — Wed, 31 Aug 2011 16:19:51 +0000

Simon- I agree with your sentiments: an important (but often unstated) job of an architect should be to sustain the ability of the software system to adapt and grow.

The architect whose story I was recounting was not making a duct tape solution in my opinion. Instead he made minimal changes to improve the system and left the inconsistent existing logging code intact. Not ideal, but not harmful, either. He didn’t increase the entropy of the system by his “fix”. When you can fix a problem this way, you are lucky. As a matter of principle, if you can shore up your architecture, make changes and enhancements, while continuing to encapsulate the poorly designed parts, you are doing OK.

Too often, however, duct tape solutions are applied deep in the bowels of systems. As a consequence, code and data become even more tangled and incomprehensible. And it becomes increasingly difficult to make repairs or enhancements.

Comment on An Architect’s Dilemna: Should I Rework or Exploit Legacy Architecture? by Simon

Simon — Wed, 31 Aug 2011 15:04:03 +0000

I see this very often in the wild. While as a software engineer I pride myself on architecturally inspired designs and implementations, when you’re not the only chef in the kitchen it is impractical to expect there to exist a single vision for how things are to be done. It’s hard enough keeping your own designs and implementations consistent over time, let alone expecting a distributed team do so also. So cruft is plentiful.

One of the biggest challenges I see is that corporations care about little more than shipping code. While I agree that shipping code is job #1, there are many other important jobs (let’s call them job #2, #3 and #4) that, while important, are more often than not, neglected. Sadly, focusing solely on job #1 results in much accumulated technical debt which, over time, burdens the system and can ultimately prevent job #1 from being completed. So what to do? Well, you can achieve almost anything if you use enough duct tape! But that does not tickle the right part of my brain!

So I know how it feels to want to land the plane, take it apart, and rebuild it piece by piece. But sadly that is never practical despite the obvious benefits. So we’re left with architecturally ugly solutions that are applied to keep the plane flying, regardless of the technical debt it might incur.

Comment on Can you really estimate complexity with use cases? by J A Schwartz

J A Schwartz — Fri, 08 Jul 2011 17:35:19 +0000

Even in a Use Case course or an Object Design course, why not put a Conceptual model in the hub. Usage, states, UI, object collaboration, data descriptions, etc. are all grounded by concepts and their relationships.

Comment on Agile Architecture Myths #1 Simple Design is Always Better by J A Schwartz

J A Schwartz — Thu, 07 Jul 2011 17:14:06 +0000

I agree with Daniel. Many places I’ve worked or consulted at, the norm is “Ready, Shoot, Aim.” Even when projects are billed as a total make-over, they often don’t touch the more complex appearing aspects of the old system – usually the persistent and/ or domain layers. Instead the presentation layer is just reworked – lipstick on a …

I have, however, been associated with shops where OOAD is a valued activity. I remember a comment that a friend once told me, “Once you work for an organization with a mature OOAD methodology, you’re never willing to go back to the OK Corrall style of software development.

Comment on Agile Architecture Myths #3 Good Architecture Emerges by J A Schwartz

J A Schwartz — Thu, 07 Jul 2011 16:50:42 +0000

Many aspects or artifacts of the software development process are only attended to if they are valued by the organization. So while individuals may have the skills, chops and know-how to initially address or readdress architectural issues; if the only valued outcome of a software development effort is working code, architectural issues may be ignored.

An interesting exercise is to conduct a ‘Value Model.’

Comment on Draw a Tree by Crazyzoar

Crazyzoar — Tue, 07 Jun 2011 11:54:25 +0000

Drawing is a form of visual expression and is one of the major forms within the visual arts. There are a number of subcategories of drawing, including cartooning. Certain drawing methods or approaches, such as “doodling” and other informal kinds of drawing such as drawing on a foggy mirror caused by the steam from a shower, or the surrealist method of “entopic graphomania”, in which dots are made at the sites of impurities in a blank sheet of paper, and lines are then made between the dots, may or may not be considered as part of “drawing” as a “fine art.” Likewise tracing, drawing on a thin piece of paper, sometimes designed for that purpose (tracing paper), around the outline of preexisting shapes that show through this paper, is also not considered fine art, although it may be part of the draughtsman’s preparation.

Comment on Draw a Tree by Crazyzoar

Crazyzoar — Tue, 07 Jun 2011 06:02:41 +0000

Britannica Online defines art as “the use of skill and imagination in the creation of aesthetic objects, environments, or experiences that can be shared with others.” By this definition of the word, artistic works have existed for almost as long as humankind: from early pre-historic art to contemporary art; however, some theories restrict the concept to modern Western societies. Adorno said in 1970, “It is now taken for granted that nothing which concerns art can be taken for granted any more: neither art itself, nor art in relationship to the whole, nor even the right of art to exist

Comment on Agile Architecture Myths #3 Good Architecture Emerges by Rebecca

Rebecca — Fri, 13 May 2011 23:31:12 +0000

Jukka-I would be interested in hearing more about why the whole architecture concept in IT annoys you. I suspect it has a lot to do with the fact that architecture is used in too many ways: enterprise architecture, solutions architecture, systems architecture, technical architecture, business architecture…etc., etc.
But my thinking about what software architecture is quite different. It is those fundamental choices and design decisions that impact the way you develop and deliver functionality. Pnce you’ve made an architecture decision (and then implemented significant functionality based on it) then it is hard (not impossible) to change. So, for example, the choice of a particular presentation framework can be an architecturally relevant decision…so too, can be the way you decide to do authentication or authorization, how you integrate services, even the design of critical service interfaces….

Thanks for the pointer to your blog entry. Your notion of an “eternal architecture” / “thought pattern” is a little higher level than what I mean. These seem to be high-level (or abstract). They are patterns for architecture (or styles), not architecture realizations.

Comment on Agile Architecture Myths #3 Good Architecture Emerges by Rebecca

Rebecca — Fri, 13 May 2011 23:16:50 +0000

Nadya- Yep. Architecture that just “happens” may not be what you want. Declaring a design spike works fine if the team is small, capable and tcan push back at times and not just let feature delivery always drive development. One way to manage architectural tasks for a larger project or program is to tag product backlog items that require architectural work or decisions. Those that do shouldn’t be worked on until the architecture is ready enough. Rather than just add in these tasks to the regular project background it may make more sense to have a separate backlog (or a kanban) for them. Often architecture-related tasks may not fit neatly into a sprint cadence (they may be hard to estimate and/or spawn even more tasks as you get into them). That’s one reason to keep them off the regular “sprint” backlog, yet still track their progress. The benefit of a kanban (instead of a scrum backlog) is that tasks don’t need to be sized to fit into an iteration.

I plan on blogging a lot more about various approaches (and they are discussed our new Agile Architecture workshop that I’ve developed with Johanna Rothman.

Managing agile projects so that architecture gets the attention it deserves involves first recognizing that it is important, and then putting processes and practices in place to support it.