Posts Tagged "architecture"

The Argument for Emergent Design

Posted on Jul 30, 2014 | 0 comments

The Argument for Emergent Design

The Opposition Argument Let’s start off this post by exploring the arguments against emergent design. I often hear many different arguments and reasons to oppose emergent design, so I will share the few that I hear most often. First, I often hear that emergent design leads to wasted effort because building a product that only supports a small initial set of customer needs will later require the product development team to rebuild the entire product (or a substantial piece) in order to support more advanced customer needs. The wasted effort comes from the rework that the development team needs to perform in order to build the advanced features on top of the naively simple system. It follows that if the development team had asked about the advanced features before starting work, then the product could have been built from the beginning to support both the simple and more complex cases. Almost every experienced developer has several horror stories that they can very quickly relate about a poorly planned project where they endured the hardship of throwing away hours of work because the project direction (though, seemingly not the customer’s needs) changed frequently and dramatically. In addition to this, I also often hear that emergent design leads to poor system architecture because developers do not align their current efforts with a greater picture at the outset. Without steadfast direction, developers create code that works, but lacks cohesion and tends to feel more complex than necessary. After a long enough timeline of working without a big picture, the overall system architecture suffers. Almost every experienced developer has several horror stories that they can very quickly relate about a poorly designed system that was impossible to update or maintain because the system lacked a cohesive overall system architecture. While I have definitely heard many more arguments against emergent design, I have heard these two far more often than any of the others, so I want to explore these problems a little bit deeper. Product Rework and Bad Design I ask you to set aside any preconceptions for a brief moment while we try to discover the root causes of bad design and product rework. In my experience, product teams typically blame product rework and bad design on poor or inadequate initial planning. That is, if we spend more time on planning, or plan in a more skillful, careful, or comprehensive manner, then the outcome of bad design and rework can be avoided. This seems logical at first glance, so very few people give this a second thought, and attempt to solve these problems by bolstering planning activities. Improved planning generally leads to better outcomes, which gives us the impression that we have solved the problems, until they reoccur. But they do reoccur so frequently in software development that it has led some teams into a state we sometimes refer to as “analysis paralysis.” That means that the product development team cannot make any progress on the product because all of their time is spent in planning activities. The problem of bad design and rework cannot be completely solved by better planning, but both proponents and opponents of emergent design agree on one thing: The best designs tend to emerge from product development teams that have a very deep and complete understanding of a problem and its solution. So, if better planning does not completely prepare us for success, then what else must we do? True Emergent Design Great planning will only take a team so far because it is only one source of information and learning. In particular, planning typically revolves around certain constrained activities such as lengthy conversations with colleagues and customers, documenting decisions, drawing diagrams,...

Read More

Let ‘Form Follow Function’

Posted on Jan 23, 2014 | 0 comments

Let ‘Form Follow Function’

There is a reason that your frisbee is shaped like a disc… And it isn’t just because the manufacturer sells more frisbees that way!  In this post we will explore some novel ways to apply this concept to building a software product that will not only save you time and energy during product development but also lead to better designs for your products.   Certainly, you have heard the phrase “form follows function,” right? Well, if you haven’t, the concept is very straightforward: the form or design of an object is largely influenced by the function or purpose it is meant to serve.  There are numerous ways to define what we mean by “form” or by “function” in a software context, so let’s start out with some common definitions for these things.  Generally speaking, the form of a software product can be defined as its user interface.  The function of a software product, therefore, may be defined as the benefits or features that it offers to its users.  Despite these definitions, the point I’m trying to make is different and more subtle than “let your user interface be dictated by your software product features”, so bear with me.  The subtlety lies in the definition we use for “follow,” among other things. Before we jump to the definition of “follow”, however, let’s talk for a moment about the way that typical software products are conceived.  In organizations large and small, software products often begin with the user interface or a description of the user interface.  Sketches and mock ups of interfaces usually help to create a better visual picture of what the software will do, and in particular, how its users will interact with it.  This is logical because people who use software are also the ones defining new products, and their window into the product is through its interface.  Just prior to creating UI sketches, we tend to talk about what a software product does.  “What does (or will) it do?” is usually the first question people will ask our software product visionaries.  The question we should be asking first and foremost is: “what problem does (or will) the software solve?” Until we can let go of the question “what does it do?” we will never be able to shift away from conceiving of software products apart from their user interfaces, but there are big benefits to this type of lateral thinking. Let’s return now to the definition of the term “follow.”  When originally conceived, the “form follows function” phrase was meant to define “follows” as “influenced by” or perhaps even “dictated by.”  This is not the definition that I want to use in the software product context.  Rather, let’s use the first definition we find in the dictionary: “to come after.”  This is more of a temporal definition that has to do with the logical ordering of things in time.  So, in our software product context… Let the user interface come after the benefits and features have been realized. This may either seem like nonsense to you or totally obvious, but it’s neither an impossible challenge nor a suggestion to build N-tier enterprise software starting with the data model layer and finishing with the UI layer.  Allow me to clarify with examples. Ultimately, your product is built by a software development team We need a way to define the product so that it can be built by the team.  If we were trying to answer the question “what does it do?” then we might define our product as a set of software “requirements,” such as “the software shall display a modal...

Read More