Global Software Development — Foundations — Understanding the mission

Posted on January 6, 2014 by Mike Rodbell

Fork in road

If you want to get where you wish, know what you wish.

The Cheshire cat was on to something. (shhh, don’t tell the dogs, I have some partiality to cats).

Putting first things first, be sure you know what you want to accomplish.  Absent that, you may not much like what you get. Its alright for some amount of fuzziness, but I’d be careful to not tolerate too much. If your vision is a hopeless mystery, save yourself lots of time, aggravation and money, and invest some time to figure out what it is that you’re hoping to accomplish. For now, lets concentrate on the high level goals (independent of the specifics of the work).

I’d mentioned several objectives in the beginning of this series. Some pretty typical examples include:

  • save money by moving work to a place where labor costs less (beware of mythical man-months etc.) Folks in finance frequently gravitate towards this goal. They also assume that all of us wondrous software people can figure out how to get the same work done with the same amount of people while discounting access to information, learning curves, skills, time zones, travel, and the sad fact that we’re all human/mortal.
  • accelerate development efforts because its easier to get the right resources in different places.
  • use different development centers because that’s just how its done and you’ve been given a directive to take a different course (not my favorite, but one that can occur in larger companies seeking economies of scale and consistent patterns of behavior).
  • reduce the risks associated with your current organizational structure. A few examples of this include stiff competition for resources, over-reliance on outsourced organizations or whomever the status-quo may be.

These speak to the higher level goals of why go to other locations rather than organic growth in your current location(s). There are also the obvious questions about what it is that the team will be doing once established. I’ll leave that for another post.

Recognizing your goals, you’ll also want to be certain to create a vision of what your end state is (things tend to not end, just evolve, still, I think its worthwhile to set some targets), how much you’re able to invest, and how you plan on getting there.  So in the end of the beginning (apologies for my clumsy prose), you want to know:

  • what you’re doing
  • how you’re doing it
  • how much you can afford to spend
  • how much you can afford to not do (had you stayed the prior course).
  • Given that you’re going to need to make some investment, be confident that those investments are considered in the broader cost of the efforts, both in terms of opportunities lost and added expenditures (labor, travel, etc.) required to get the new team up and running.

Many of these objectives are achievable. All are fairly involved. As you build out your plans to shift work around, be as clear as you can regarding your goals, and wherever possible, establish and validate the assumptions that you’ll use to chart the path to your end state, whatever that may be.

Advertisement
Posted in Uncategorized | Tagged , , , , | 1 Comment

Global Software Development Processes/Approaches

Posted on January 3, 2014 by Mike Rodbell

Following up on my last post, I thought it might be helpful to review some approaches to establishing and running new teams at different sites. I’d originally thought of just calling them processes, but I suspect that may be doing the topic a bit of a disservice, in that the term process could be assumed to mean a set of specific actions.

While there are some general practices that work, one caution that I’d offer is that its almost impossible to plan for every situation. You’re probably better served by anticipating the most significant scenarios, and being on the ready for all sorts of things to occur. Attempts to rigidly control your project may just be a lot of wasted effort and drive somewhat fruitless hypothetical conversations.

Some of the major activities that you’ll want to be prepared to address include:

There’s a lot to think about. I’ll review some thoughts for the initial setup, then follow up on the other topics in subsequent posts. As I had mentioned in my previous post, there’s a lot to think about. My hope is to share some of the more important aspects to provide a feel for what you should consider.

As I add posts to cover each of these topics, I’ll provide some links. Look at this post as an introduction/outline to a much larger topic. Also, if you have any thoughts, comments or questions, please feel free to chime in. This is a pretty involved, and interesting topic.

Posted in Distributed Teams, management, software development, travel, Uncategorized | Tagged , , , | 6 Comments

Global Software Development

Posted on December 18, 2013 by Mike Rodbell

earth

Early in my career, I worked with people who sat across the room from me, perhaps at times in the room next door. Back then, it didn’t take much to meet and discuss work with my co-workers. This was pretty much the norm in the 80’s and 90’s.

But wow, things have changed. Most (well all) of the large technology companies I’ve worked for find themselves in a new world where development teams are spread all over the place. This occurs for a number of reasons:

  • It is much easier to work with teams all over the world. With the incredible advances in networking technologies, its far easier and less expensive to communicate with people all over the world. I’m very proud of the work we accomplished at CIENA as a part of that boom. There were some incredible advances we were able to achieve in significantly reducing the cost of bandwidth. In kind, the carriers drove down the infrastructure and subsequent advances in networking technologies have led to new, incredible possibilities.
  • Companies, large and small, merge with one another. Its not unusual for those mergers and acquisitions to involve companies with headquarters on different continents.
  • Companies find themselves pressured to reduce costs, while still needing to meet development objectives. While this isn’t a terribly popular topic amongst employees becoming displaced in traditional western nations, it is a very definite factor in the high tech world. For the most part, folks in the US with good software engineering skills continue to be in high demand.
  • Companies may need to expand at a rate that they can’t support in their primary locations. It may be easier to find the needed talent in other locations.

Regardless of the reasons for making the shift from having a geographically co-located team to a distributed team, there are a bunch of things to consider. These apply both when first setting up the team, as well as maintaining positive momentum once the teams are established.

There are two general areas that require consideration: the things that you’d want to do any time you’re hiring new people or teams, even they were to sit under the same roof, and the things related to the the geographic change.

Regardless of location (even if in the same location), there are some things that are absolutely essential. These include:

  • Get the right leadership in place
  • Clearly understand what it is that you want them to achieve, and be certain that it passes the sniff test.
  • Hire people with the right stuff. Intellect, communication skills, EQ, etc.
  • Hire people that want to do the job. If you need to build a team that is addressing defects in existing software, hire people that enjoy doing that work. Don’t hire a bunch of architects whose passion is in building new applications. They will probably not be happy, and not stick around.
  • Create an environment in which they are able to succeed. Ideally one where they are given some autonomy and ability to develop the skills and team cohesion on their agenda.
  • Plan on a reasonable time scale for them to come up to speed. Wherever practical, narrow the focus of the new team’s activities to allow them to add value sooner rather than later. But don’t be naive. It will take time for even the smartest folks to hit full stride. Time zones, and limited access to information can impede that progress.

Then there are the things that are unique to the distributed team establishment. These include:

  • Consider the feelings of your current teams. They may look at the outsourcing or off-shoring activity as a threat. If you don’t express your intentions, your people will invent them. I think its better to have a frank conversation with the teams. It takes less energy to be candid than to put out the uncontrollable fires that result from hall talk. They may occur, but a transparent discussion will tend to help.
  • The startup costs can be significant. Understand what you hope to achieve and balance that against the effort and distractions that are involved.
  • Plan on the learning taking a bit longer, and put activities in place to help that along. Travel, structured presentations, frequent interactions amongst the teams can help.
  • Time Zones. If you’re working across several time zones, plan on having meetings where someone is going to need to be flexible.
  • Whenever possible, start with more senior folks. They will be a huge help in recruiting the right team, helping with the training process, and being both your, and the teams voice.
  • Engage people across sites. This can help ensure that the right work is being done, and over time, can build stronger working relationships that can be extremely helpful.
  • Treat the new team as you would any other. Give them sufficient latitude to contribute, and be proud of their contributions. There can be a tendency to micro-manage the new teams. Rather than directing specific actions, its often better to work in a mode that provides them with objectives and coaching towards success. We’ve found that greater ownership, responsibility, and the ability to verify the new team’s success pay significant dividends.
  • Plan on as much interaction as possible. With services like skype, and other video conferencing, you will find the benefits of the efforts huge.
  • Visit the team. Once people get to know one another, its far easier to communicate and collaborate.

Establishing and leading a distributed organization has its own set of challenges and opportunities. When done well, it can be a tremendously rewarding experience. The teams benefit from added diversity and I’ve found the experience of meeting and working with people across the world as a fascinating opportunity to learn more about the world and people’s views.

Posted in Agility, Distributed Teams, Group Dynamics, management, morale, software development, travel, Uncategorized | Tagged , , , | 1 Comment

Innovation Redux — fitting the corporate world

Posted on December 8, 2013 by Mike Rodbell

innovation

I happened across an interesting article in the Harvard Business Review (stop me before I “innovate” again) this morning. The author’s premise seemed to be that everyone is so anxious to declare themselves as innovators that they lay claim to nifty (or not so nifty) things (e.g., peanut butter pop-tarts as flagged by the Wall Street Journal blog) as the next great thing. I guess beauty is in the eye of the beholder. I also wonder a bit (again) about how to define innovation. Websters defines innovation as:

“in·no·va·tion

 noun \ˌi-nə-ˈvā-shən\

: a new idea, device, or method

: the act or process of introducing new ideas, devices, or methods”

So, while the cynic’s view of the nifty new pop-tarts is that its follow & a reach, a more formal interpretation could be used to side with Kellogg CEO claiming that peanut-butter pop-tarts are indeed something new (if admittedly derivative). For that matter, I’d bet that someone, somewhere woke up one morning and went “hey! I have a great idea. Lets put peanut butter in a pop-tart and won’t that be incredible.”

The timing of this (for me) is particularly interesting on a few fronts. I’ve recently gone full tilt into a combination of consulting and reviewing opportunities for a tech leadership position in new firms, and have just completed an online course in Organizational Design through Stanford/Coursera. Pulling all of these together, I’m arriving at some conclusions. While the people in the WSJ may scoff at what Kellogg’s has done (perhaps the true innovation is taking something mundane and making it seem like more than it really is), there very well may be something there.

The nature of innovations is particularly important when framed in the context of business. Most (probably all) business advances are derivative, with much of the “innovation” coming from some unique and valuable combination of ideas, technologies and business processes. Imagine what would have happened had Apple not been so clever with their marketing and go-to-market strategy of the iPhone. In reality, it doesn’t do a heck of a lot more than the smart phones that preceded it. What it did do was tie into other systems and perceptions in a way that no other vendor had been able to capture. Viola! Something derivative became disruptive. In a major way. I’ve had the good fortune to be a part of those sorts of things in the past & that class of innovation can lead to mind-boggling results.

So I’ve arrived at a few conclusions (which will no doubt change over time), including:

  • To survive in the long run, businesses absolutely must adjust the product or service that they provide. Even if their offerings remain valuable, someone else is going to find a way to provide a better or cheaper (or both) alternative.
  • Some companies have an end game in mind. They build something, sell a bunch of it, and find a way to make that interesting to another firm to become acquired.
  • Some companies make their money, then wither and fade from view because they aren’t able to keep pace with the business environment in which they live.
  • Some companies are fortunate enough to create a special balance of valuable offerings, new innovations, along with the ability to change and not become burdened with debt, whether it be in the form of financial obligations, or ongoing commitments to support declining product lines or offerings.

The history of innovation is littered with derivative products. The Beatles unabashedly borrowed from blues artists and bach, the iPhone took mobile computing beyond the blackberry, Windows borrowed (some may stay stole) heavily from the Mac, which took a lot of its inspiration from earlier work at Xerox PARC (check this out).

So, while this may be a bit of a contrarian view, perhaps peanut butter pop-tarts are kind of innovative? For me, I was always partial to the brown-sugar cinnamon variety. Now, I need to watch my weight…..

Posted in Agility, Change and Behavior, Innovation, management, Product Management, Uncategorized | Tagged , , , , , | Leave a comment

Success!

Posted on November 20, 2011 by Mike Rodbell

Success. What an interesting concept. A simple word that means something different to different people at different times.

As an example, I just finished stacking a cord of wood. I was pretty happy when it was done. Went from an unruly pile of wood in the middle of the driveway to a neatly stacked pile of wood in the corner.  This isn’t something I do very often. Given that the Maryland winters aren’t generally very harsh (lets forget about the blizzard a few years back, PLEASE!), stacking wood isn’t something I do all that often. Still, there was that feeling of success when I was done. I’d accomplished my goal. Was nice to see it done.

Success in life, particularly in the corporate world isn’t always as simple to measure. A friend of mine posted a link to an interesting Forbes magazine article written by Steve Denning about the things that make companies compete. Its about why big companies often fail. The premise (referencing Apple’s success under Steve Jobs) is that many companies fall prey to short term financial (cost containment by the finance people or revenue acquisition by the sales pros) and forget about developing new products for future success. In fact, these organizations are doing their level best to contain the risk of failure, and may very well be encouraging the failures they seek to avoid. Setting aside the fact that my career has been largely spent on worrying about building and supporting products, this got me thinking about what motivates people and finding the secret sauce that leads to sustained (at least for a while) success of companies like Apple.  Not a simple matter!

There are very clearly different types of success. Short term, immediate success, while challenging is relatively easy to achieve. Figure out what you want to accomplish, how to go about it, and assuming that you have the skills and resources, have at it. The type of success that Denning (and Jobs) argue for is a sustainable success. Doing that requires an interesting combination of successes, with none trumping the others. The success that they argue for is one in which companies allow themselves to create a continuous stream of success. That is not a trivial matter. Very few companies live forever, let alone technology companies sustaining more than a decade or so of stability and growth.

Many business texts have been written about how organizations can be built for the long haul. Leadership pipelines, planning, etc. One of the main points of the article is that companies all too often find themselves shifting from their initial successes associated with compelling products into modes where they worry more about driving revenues and/or containing costs. Both a focus on sales and fiscal responsibility are no doubt responsibilities, however if associated with a decline in attention to the products that bred the success can (and generally will) lead to a decline in future success. Attention must continue on all fronts. Success is born out of doing the important things well.

So the answer is…. Do everything that’s important, and do it well. Focus on balance, and the odds of sustained success (and growth) and your odds of success increase. Measure yourself and your teams against continued progress with interim

Thank goodness that life brings opportunities for individual success and little things. Like stepping back & looking at a cord of wood no longer cluttering the driveway.

Posted in Competition, Innovation, management, Product Management, Uncategorized | Tagged , , , , , , | 2 Comments

Awesome

Posted on June 25, 2011 by Mike Rodbell

Been away for a while. Not that I’ve vanished, but somehow stopped blogging for a bit.

I was looking for something interesting on the internet the other day. This is kind of like my digital version of wandering around the library when studying in college. I’d love to pick a random shelf of books & start perusing. It’s often seemed different on the internet, while there’s ton’s of interesting stuff, there’s an overwhelming amount of dribble (perhaps this blog is in that bucket!?!?!). Anyways, one of my favorite sites is www.ted.com, with a steady stream of pretty thoughtful stuff. While on that, I stumbled across Neil Pasricha’s talk on TED about the “Three A’s of Awesome”.  Thought provoking stuff & definitely resonates.

Pasricha has a great story of growing up, having some big ups and even bigger downs & how he responded. Clever guy who thought to start writing a blog about all of the amazing things in life. For him, focusing on the positive was a great tonic for some really sad events (death of a close friend, divorce). It also turned into a career path. He’s gone on to publishing a series of books & is amassing quite a following. Great stuff!

So, my own observation of awesome, at least for today is the silicon tape that somebody invented to seal plumbing leaks. My very not awesome start to the day occurred when woken (extremely early) by my wife calling me from the kitchen. Turns out that our 20+ year old refrigerator’s ice maker hose feed sprung a pin-hole leak. Its amazing the amount of water that can spew all over the kitchen in a not very long period of time.

So, there were actually two (at least) awesome things that occurred to us this morning:

  • Someone was around to notice that there was water being pumped all over our kitchen floor (and with gravity’s help, into our basement).
  • I was able to figure out what was happening, cut the water & get out to the hardware store to purchase some of that tape.

We’re now back & running. I’m dreading the repair bill to replace the home (err, I mean hose… which really needs to go). When I looked at the way it was installed, it appears to be snaked through the wall from some mysterious place in the basement ceiling. That will be next week’s adventure.

But back to the original impetus for my post… I was very taken by the author’s outlook on life and enthusiasm. When I think of some of the happier people I’ve been around (and enjoy being around), they somehow manage to capture some of the same enthusiasm for life and the world around us. There are almost always good and bad things to focus on. Somehow, the focus on the positive seems ever so much more appealing.

Imagine surrounding yourself with people who are able to see the world in this way. Assuming that they’re not completely nuts (which is a possibility!), what an awesome way to spend one’s days…

Oh, one other amazing thing, we just checked out some new kittens. We’d lost our 19 year old siamese-cat, rosie earlier this year. This one is going to be joining us in about a month’s time….

Katy's new cat

our new cat

Posted in animals, Change and Behavior, Innovation, management, morale | Tagged , , , , | 2 Comments

Agility Product Strategies — Dimensions to Consider

Posted on April 9, 2011 by Mike Rodbell

In the software world, agility often starts with the development team. That’s nice, but generally only a part of the solution. By creating a value stream, interesting opportunities and dilemmas abound. Unless the whole supply and value chains are aligned, the benefits of agility can be lost. In some cases, the agility itself can present a dilemma.

This is one that’s led to some interesting conversations. In a fully agile development shop, products are (theoretically) available at the end of every sprint. Could be that something new and interesting comes popping out every two weeks. While the tech folks may have been disciplined and productive enough to make this a possibility, some interesting dynamics start to appear. Stuff to ponder:

  • for a distributed product, can the delivery chain reasonably absorb an ever-increasing catalog of slightly different versions of products?
  • can the support organization keep pace? Will they be able to discern the differences from one version of the product over the other?
  • At what frequency does the consumer want to use new versions of the software?
  • If a product to be deployed (rather than shipped), is the technical operations organization ready?
  • Are there other production chain considerations (you’ve just become someone’s supply chain)?

These questions seem to point to a situation where the organization best be mindful of the downstream constraints. The software development organization may very well have done a phenomenal job of producing a steady stream of exciting and valuable features. However, the trick is to ensure that the perceived value of those capabilities is sufficient to distinguish the product within the marketplace.

Some questions that lead me to look at the other side (get new features delivered as quickly as possible) include:

  • Can you capture & retain market mind-share? Products are exciting for only so long. There are some analogies that I’ve seen drawn between agile processes and the psychology of game playing. Many product strategies are based off of engaging your audience in a way that they not only like what they have purchased, but grow their relationship/engagement with the product as they regularly adopt new techniques and features that help them derive even greater value. Get people in the habit of coming back for more & all kinds of good things may happen!
  • What are your competitors doing? If they’re going silent for long periods of time, a regular set of releases may keep you in full view, with a great opportunity to retain mind share. This could be a valuable part of your product strategy. We live in a “what did  you do for me yesterday” type of world. This can create a series of productive “yesterdays”

This presents a set of interesting alternatives, that can have a range of results:

  • go ahead and release the product at the end of each sprint. In a SaaS environment, this could be fine, provided the changes don’t cause confusion within the user community. In a shippable product world, this could be a challenge.
  • accumulate enough changes/improvements in the product to make a “big splash.” This may take more time, and if you’re not careful, can lead to pronounced delays in the delivery of the final product.

Most organizations find a happy medium.

Wrapping up, what are the conclusions that can be drawn? Agile development alone isn’t going to cut it; everyone needs to consider what they’re doing in a lean organization. If you engage and consider all participants in your product life-cycle, there are some pretty interesting things to consider. When laying out a product feature strategy, there’s plenty to consider!

Posted in Competition, Innovation, Product Management | Tagged , , , , | Leave a comment

SCRUM and the Brain — Why Agile Development Works

Posted on March 15, 2011 by Mike Rodbell

I just finished reading a great book about how our cranial physiology impacts our behavior and ability to think and interact effectively. The book is called “Your Brain at Work” by David Rock. I enjoyed reading it and found a good number of useful references.

One of the things I started to realize was that the framework presented in this book helped provide a great perspective on why I’d seen so much success with Agile SCRUM. Several things came to mind:

1. In SCRUM, there’s heavy emphasis on letting the “pigs” on the team focus on their work, and not take on too much at any one time. Work is managed in a serial, prioritized stream with individual work items brought to completion prior to taking on additional tasks. In the context of the book, there’s considerable discussion about the limitations of the pre-frontal cortex, where people are best able to take on active thinking tasks, one thing at a time.  In addition, trying to do too many things at once can have a significant effect on your IQ. And not a good one.

2. People naturally crave and require regular human interaction. With it, positive feelings emerge, which are key drivers of success. In SCRUM, there’s a significant emphasis on continuous interaction.  Daily standups, open communications are front and center in SCRUM.

3. People are hard-wired to gain momentum when working towards something (rather than away). With SCRUM, there are always a new set of goals, that are (or should be) well within reach. Teams are encouraged to work towards those goals. Emphasis is on positive accomplishments. Done well, good things become contagious.

4. People crave and require human interaction. As contrasted to waterfall processes, where it’s very easy for someone to go hide in their corner for extended periods of time, there shouldn’t be a day that goes by without some meaningful interaction. Even if its only the daily standup, everyone should have something to say and be collaborating.

5. Good behaviors are learned through modelling and repetition. Everything about agile, and SCRUM revolves around getting into a rhythm and sticking to it. Those repetitions can become ingrained, providing a great environment for acceleration.

SCRUM is certainly not the only place where these things can occur, but I find it interesting the ways in which setting these patterns in the workplace can correspond to the very fundamental characteristics of the human brain. No wonder this stuff works so well! (and even better that people aren’t bashing their heads into one another).

Posted in Change and Behavior, SCRUM, software development | Tagged , , , , | 2 Comments

Software Design — Art? Random observations

Posted on March 12, 2011 by Mike Rodbell

Had a number of comments back to my earlier post asking whether software design was art or science. From the sampling, which was highly self selecting & amongst a number of old friends/acquaintances, there was an overwhelming sentiment that software design is unequivocably art. I also had some more time to think about this stuff, having been very busy with the team in Detroit. Good trip, great getting to meet and spend some time with new associates from OpenText. Also, very glad to be back home!

A strong proponent of good design being analogous to art and art-minded people (well, right-brained anyhow). An interesting observation by Frederick Brooks in “The Design of Design” “the Waterfall Model is wrong and harmful; we must outgrow it.”  Like art, design is a non-sequential process that, when done well, requires significant iteration and successive discovery. At the risk of turning this into a book report (I’m liking his book, by the way), he also makes reference to a term he’s coined “conceptual integrity” which refers to a design following a theme/pattern/or message. While these sorts of things can be born out of science and/or nature, they tend to permeate the world of art. (another very weak argument that design is art).

I’m pretty squarely on the side of art, but an art that somehow needs to be harnessed. The discipline of design, and in many cases, maintenance is a craft (art) in which I’ve observed massive variance in people’s abilities and throughputs, even when there’s evidence (similar educational backgrounds, experience) that would point to some inherent aspects that relate to individual’s right side of their brain and abilities to visualize and conceive of valuable creations, much like art.

The big dilemma (for me anyhow, and I’m sure many folks), is that even though this has the qualities of art, there’s an economic imperative to somehow turn it into a predictable science. Herd some cats, anyone?

Posted in management, software development | 2 Comments

Software Design — Art or Science?

Posted on March 9, 2011 by Mike Rodbell

I started reading a new book (at least to me) that looks promising “The Design of Design” by Frederick Brooks, the guy who came up with “The mythical man month.”  On first glance, I’m very pleased to see that this book reinforces many things I’ve come to believe are somewhat self evident. To design something, you have to be able to visualize things a bit differently, and its complete folly to think that you can know everything from the onset (or for that matter, ever).

This may apply to anything that falls into the world of knowledge work for which there are end products (a subset of things people do that is primarily an intellectual pursuit. There are certainly other examples of this kind of work, architecture, the arts, music composition, creative design. Things that people do to conceive of and create an end product that wasn’t clearly defined when they started.

Perhaps software can be developed like it’s a car being assembled on a production line similar to the ones Henry Ford conceived for the Model-T? There’s a school of thought that software is something that can be created using a very linear, methodical process. Understand your requirements, sift through the options to fulfill the requirements, identifying the path that best balances a bunch of alternative approaches, decompose the aspects of that path, divvy up the work amongst a bunch of contributors, have the contributors do the work, have the contributors test their work, pull the pieces together, test the integrated pieces, fix the integrated pieces, test again, write a bunch of documentation, and ship/deploy/whatever you will with the end product. You could do this with pretty unimaginative folks, not a lot of room for mistakes, right? (probably also not a whole lot of room for great things either).

Neat and clean, right? Not often, actually, pretty rarely. Requirements are frequently misunderstood, they change, what may have seemed like the best alternatives may have really been laden with disappointment. Besides that, what fun is it to work in a mode like this? Kind of seems like the first part of the Wizard of Oz. You remember right? The part where everything’s in black and white. Or what was that other movie where it shifted into a color world once the main characters discovered other enticements, much to the dismay of the town fathers (no mothers, mind you)…

I think that the best designs and design processes are a bit messier than this. Have you ever had an opportunity to review some of the process that the great artists have followed. It’s not uncommon for them to have sketch upon sketch, rework designs, and so forth. Thankfully, the software process can lend itself to that, while allowing a place for the rigor needed to ensure that whatever concoction the team cooks up, it can be reasonably proven to work in a way that satisfies its constituency. Users should be able to review and reflect on incremental work products, and have that feedback incorporated into a sustainable product.

I can recall being around folks who had a knack for pulling together sustainable designs. In almost all cases, they could express their designs in a visual sense, much as I’d imagine an artist conceiving of their creations. abstract concepts, that largely ended up manifest in a series of mundane statements come together in a framework more easily understood as collections of objects knitted together in cleanly defined inheritance, containment, relational, and interaction hierarchies. When assembled, these artifacts lend themselves to assemblies that directly address user requirements.

My answer to the question is that the answer is “yes, a bit of both” Keeps things interesting.

Posted in Innovation, software development | Tagged , , | Leave a comment