Culture, Data, Networks, People February 23, 2012 1 Comment

I gave a talk a few nights ago, Data, Networks, Culture, Data – or How to be a total baller when it comes to executing on ideas.  The talk analyzed when I felt like I was making something people wanted and the four common themes in all of those situations: Data, Culture, Networks, People (my slides for the talk)

Grok it, Rock it, Drop it February 20, 2012 3 Comments

Quickly evaluating ways to simplify your problem space is an essential problem solving skill.1  However, this is extremely difficult to do in fields where possible solutions are rapidly growing (like software).  To overcome this, I present Grok It, Rock It, Drop It.

The goal is simple: Continually be learning something new.  Experiment and explore the new material or technology.  Integrate the knowledge or technology and use the integration as the platform to launch into a new learning area.  Following these three steps will allow you to quickly evaluate technology and effortlessly adopt it.

Grok It

Continual learning is essential for producing an ideal solution to a problem.  Getting in the habit of constantly reading, discovering, evaluating, and discussing new technologies grows your toolbox of approaches and maps out solution spaces for classes of problems. Deciding what to learn and how much to learn is tricky.  Follow your own curiosity or try Just Enough Learning.2
Identify areas of your problem that are high risk (if you get them wrong, your entire solution is guaranteed to fail) and areas of deep impact (where an ideal solution greatly reduces the overall problem).  Spend no more than one hour quickly searching Google, Google Scholar, and tech news resources.  Identify the few ideas, concepts, or tools to Rock.

Rock It

Pick the technologies up and USE THEM.  Go beyond recreating an example.  Use the technology to solve a subset or possible subset of your problem.  Your goal should be understanding the benefits, tradeoffs, and limitations to the technology.  This is raw validation by means of a prototype.

Drop It

Integrate.  Right now, do it.  Integrate the knowledge you gained in better focusing your own approach or integrate the technology.  The more often you integrate smaller pieces that simplify your problem, the quicker you’ll arrive at an ideal solution.  The natural byproduct of integration is a new perspective to tackle another area in the problem space, launching you back into a phase of learning and exploration.

  1. This is greatly stressed in Polya’s How to Solve It []
  2. This term is glommed from the book, Just Enough Software Architecture []

The power of cultures January 11, 2012 No Comments

Our world and behaviors are shaped by the cultures and rules that conform it. 1  The power of people and the culture they embrace are some of the most powerful tools in the software engineer’s toolbox, and are also the greatest hurdles.  The best solution to any problem is the non-technical solution, that uses the power of culture and community to achieve a greater goal.2

Engineering Cultures

There are many examples of the deep impact positive cultures have on their populations, no matter how large or small the population is.  For example, take Do-It-Yourself (DIY)- the culture and camaraderie within it have existed for decades.  It’s become a way-of-life for some individuals.  The culture is so powerful, it has even been adapted into a personality trait ala I’m a real do-it-yourself’er.

Similar effects can be found in technical organizations and even within software projects.  Ruby has had a profound effect on the approach and adoption of software testing.  TDD is the norm for Ruby developers (especially those using Rails), to a degree that wasn’t previously seen in other languages or projects.  Likewise, I’d argue that Clojure is causing a “Thinking” culture to emerge- where careful, deep, purposeful thought and dissection of the problem space are the first steps of all ideal solutions.

This concept of “purposeful culture” can be leveraged to boost your own engineering team.

A tale of engineering at Etsy

I credit my experience at Etsy as the first great example of how powerful a team/company culture can be and what results given one.  At the earlier days of Etsy, everyone was more or less equal.  The entire company (at the time I left, 65 employees), was roughly a horizontal organization.  Every idea and criticism was valuable and received the same amount of attention- as long as you had the data to back it up.
We decided as a team (and to some degree, as a family) what was important to us, what we thought we should work towards, and how we should go about doing that.  Employees were valued above everything else.  Being in a room where everyone was a first class employee not only allowed us to get to the winning ideas faster, but made everyone feel important.
Data and democracy ruled.

It didn’t stop there either.  Etsy has continued this tradition of optimizing for the employee and driving all their decisions by real data.  Chad Dickerson sums it up nicely in a talk he delivered at railsconf.

Culture’s effects on process

Effective process comes from effective cultures, not the other way around.
If you want the best possible process for your team, you must first create a culture where the natural outcome is that process.  Here are some things that worked for Etsy and have continue to work for me as I’ve built out engineering teams:

  • Strive to be objective, always.
  • Give everyone access to all points of data
  • Encourage innovation and create clear paths for bringing the fruits of labor before the group
  • Drive ownership across everyone
  • Continual and constant learning
  • Mistakes are ok, Failures are ok, Adaptation is essential
  • Ask “why” more than “what”
  1. Much work has gone into studying the network and behavioral effects of populations given different societal inputs.  See Networks, Crowds, and Markets by Easley and Kleinberg []
  2. Here I’m using powerful in the terms of “work effort over time,” based on an assumption that social interaction amongst people is solving a specific problem.  In the same regards, I’m using best to refer the lack of software/hardware/”systems” engineering in the elegant solution. []

Discussing and evaluating architectures; pt 2 July 30, 2011 No Comments

In the last installment of this series, I presented the foundations of software architecture.  To recap, they were

  • Every piece of software has an architecture, whether intentional or not
  • Every architecture is created by at least one architect
  • Architecture appears in the small (software design patterns) and in the large (architectural styles)
  • Architecture is independent of technology choice.  Abstract styles allow for composability
  • Architectures are objective, allowing us to say one architecture is more elegant, efficient, or better than another

This installment will cover how to recognize the styles being applied in an architecture through a process of analyzing for completeness, consistency, compatibility, and correctness.  The post will finish with how to evaluate an architecture after it’s gone through appropriate analysis.  The main goal here is to use purposeful, objective decision making and problem solving skills, to move forward in building the best possible system and enable us to have a higher chance of software project success.1

Analyzing an architecture

Most often architectures need manual analysis, however, there are automatic and semi-automatic analysis techniques and tools.2  I’m primarily going to be discussing how to use general inspection and review based analysis and specifically Architectural Trade-Off Analysis Method (ATAM).  Both of these methods are manual, involving discussion,3 and usually include iteration.  As always, this is just a foundation for these two methods, please feel free to adjust them for your own purposes or seek out more resources.

Terms and goals

Here is simple language used discuss and analyze architectures in an objective way:

  • Completeness – The system captures all functional and nonfunctional requirements.  The architecture itself fully captures all views and components of the system, as well as dynamic behaviors, interfaces, and contracts.
  • Consistency – The absence of contradictions within the system.  These can appear as naming or interface inconsistencies with components or connectors, behavioral inconsistencies between components, and interaction or protocol inconsistencies.
  • Compatibility – The system correctly applies and adheres to the constraints of the styles and reference architectures.  That is, you’re not trying to compose styles in an inefficient or incorrect way.
  • Correctness – A relative property that refers to if an architecture captures all design decisions and if a system’s implementation fully captures the architecture, correctly implementing all design decisions

When analyzing an architecture using this language, highlight:

  • The data exchange within the system or subsystem – most systems (especially web-based systems) are data-intensive or data-centric.  The structure of the data, the flow of data, and its general properties and characteristics should all be analyzed
  • The structural characteristics of the architecture, ie: how everything connects or if components are missing necessary connections
  • The behaviors of components
  • The interaction between components
  • The nonfunctional characteristics of all components and connectors – often the critical dimension of all software systems

Given this language and framework, architectures can be objectively inspected, discussed, compared, and analyzed.

Inspection and review

An architecture inspection and review can be thought of like a code review, but for the system’s architecture and design decisions.  Just like in a code review, quality and knowledge transfer are the two major takeaways from the process.  That is, inspection and review will find defects and shortcomings, better address design decisions, and allow all team members to fully understand the entire system’s architecture.  The scope, goal, and concern of the review is determined by the team and project, but the process is the same no matter what.

Individuals first conduct their own review, creating whatever artifacts (models, notes, written assessments, reference architectures) they feel they need.  A group then conducts a review together guided and supported by the individuals’ reviews.  This can be done in any fashion, but there are specific formats, such as the ATAM.

Architectural Trade-off Analysis Method

The details of the method can be found at the Software Engineering Institute’s site but a graph will be sufficient:

ATAM's flow

ATAM centers on a scenario based approach, which include:

  • Use-case scenarios – how the system is envisioned to be used
  • Growth scenarios – planned and envisioned modifications to the system and architecture
  • Exploratory scenarios – the limits of the architecture’s adaptability when given major changes to the functionality, operational profiles, and underlying platform

ATAM then uses technical constraints, external and integrated systems, and architectural approaches, to find the best possible match between the scenarios (which determine quality attributes of the system while expressing the requirements) and the best design decision.  ATAM is useful in that it inherently includes capacity planning, which is critical for most web systems that get deployed.

Evaluating a candidate architecture

It’s sometimes helpful to have a tangible working artifact when designing, analyzing and evaluating an architecture.  Creating a prototype or architectural skeleton are two ideal techniques, but are not substitutes for the methods described above.4  A prototype is useful in understanding how an architecture or reference architecture “holds together” or “stands up.”  For some architects, it’s an easier visualization of multiple components and connectors without getting lost in the functional and non-functional requirements.  As a consequence, prototypes prematurely force you into technology choice before a real architecture can be distinguished.  Prototypes come in two major forms:

  • Horizontal prototype – which models wide aspects of a single layer, i.e. many features with little details. The most common example for Horizontal prototype is a  user interface prototype which is used to test the overall interaction with the system.
  • Vertical prototype -Implementing some sub-system or a limited set of features across all layers /modules.

An architectural skeleton is the first iteration of a candidate architecture, trying to loosely tie together the various technology choices that make up your components and connectors.  I strongly suggest all architects do this, as it gets you to a useable product early on and allows for experimentation and exploration within a live version of the architecture.

  1. A successful project is most often defined as being on time, under budget, meeting all functional and nonfunctional requirements, and being constructed in a way that enables ease of maintenance and desirable evolution. []
  2. Automated analysis usually comes from using formal or semi-formal architectural methods, like xADL or one of SEI’s methods []
  3. Any sort of collaborative communication will work, I prefer a wiki because it documents the history of the analysis nicely []
  4. These terms were lifted from Arnon Rotem-Gal-Oz’s blog []