J.D. Meier's Blog : Software Engineering

Experience-Driven Development

J.D. Meier — Tue, 15 Sep 2009 08:46:51 GMT

Features don’t necessarily aggregate up to “experiences” and I would argue that today’s winning approach is …

… Experience-Driven Development

… Where experience means user’s can perform their goals successfully… the software makes them feel good and succeed at their goals. It’s an integration of scenarios + experiences … and persona-based scenarios with goals.

This shifts the focus to lighting up experiences over just shipping features or scenarios. It also means a focus on “Experience Step-Throughs” to model and prioritize what you ship. It seems like today’s software success is about shipping the vital few experiences that make an impact. I know it seems like a subtle shift, but I still come across too many glitches that get in the way of great software … … I think we need “experience-first” … or more “experience-driven.”

Experiences are the differentiator ... you can have scenario parity or feature parity, yet miss the boat on experience. It's beyond user stories and scenarios with acceptance tests (though that's a good start.) It's about measuring efficiency and effectiveness of the user experience.

Lessons in Software from Mike de Libero

J.D. Meier — Mon, 20 Jul 2009 07:37:19 GMT

I have a guest post, Lesson in Software from Mike de Libero, on Shaping Software. Mike was a security tester on the Microsoft Office team and has a variety of experiences under his belt. Here is a summary of his lessons:

Lesson 1. All software is flawed.
Lesson 2. Check-in often.
Lesson 3. Tests, gotta love them.
Lesson 4. Refactor, check-in and repeat.
Lesson 5. Coding is easy, humans are tough.
Lesson 6. The more eyes on your code the better.
Lesson 7. Keep learning and improving.
Lesson 8. Simple is beautiful.
Lesson 9. Learn software development not coding.
Lesson 10. Think about your audience.

You can read an explanation of the lessons in his post, Lesson in Software from Mike de Libero.

Lessons in Software from James Waletzky

J.D. Meier — Mon, 06 Jul 2009 09:21:32 GMT

I have a guest post, Lessons in Software from James Waletsky, on Shaping Software. James is a Development lead at Microsoft, with several years of coaching teams on Agile practices and software engineering under his belt. Here is a summary of his lessons:

Lesson 1. Keep it simple.
Lesson 2. Define ‘done’.
Lesson 3. Deliver incrementally and iteratively.
Lesson 4. Split scenarios into vertical slices.
Lesson 5. Continuously improve.
Lesson 6. Unit testing is the #1 quality practice.
Lesson 7. Don’t waste your time.
Lesson 8. Features are not the most important thing.
Lesson 9. Never trust anyone.
Lesson 10. Reviews without preparation are useless.

You can read an explanation of the lessons in his post, Lessons In Software from James Waletzky.

Lessons in Software from Alok Srivastava

J.D. Meier — Mon, 29 Jun 2009 21:20:48 GMT

I have a guest post, Lessons in Software from Alok Srivastava, on Shaping Software. Alok is a solution architect at Microsoft with several years of experience in large scale, distributed systems. In this post, he shares his lessons learned in software. Here is a summary of his lessons:

Lesson 1. Software development is a team sport.
Lesson 2. More lines-of-code does not mean better software.
Lesson 3. The Cloud is an inflection point.
Lesson 4. Scalability, performance and diagnostic ability are better achieved at design time.
Lesson 5. User experience and user expectation change continuously that is why UI projects are never done.
Lesson 6. Software maintainability is a key to longer life for any software.
Lesson 7. Development process should help development produce good quality software, if it comes in your way change it.
Lesson 8. Take agility with a grain of salt; result –oriented software development is what agility should help you gain.
Lesson 9. A great software engineer never stops working.
Lesson 10. Know the keys to writing great software; magic isn’t one of them.

You can read an explanation of the lessons in his post, Lessons In Software from Alok Srivastava.

Customer Connected Engineering

J.D. Meier — Tue, 19 May 2009 20:00:41 GMT

I posted slides on how we do Customer Connected Engineering at patterns & practices to Shaping Software. Customers Connected Engineering (CCE) is how we engage customers throughout our product development. We formally engage customers during the planning, development, and release of our deliverables to help make sure our deliverables are customer-driven. Customers supply the scenarios, help prioritize, and provide feedback helping reduce the gap between what we build and what customers actually need. It's effectively a prosumer model where the producer pairs with the consumers to improve the results.

Find out more about Customer Connected Engineering including key activities and guiding principles.

Agile Architecture Method Revisited

J.D. Meier — Mon, 02 Mar 2009 18:49:23 GMT

I posted an update to the Agile Architecture method on Shaping Software. When I originally posted about the Agile Architecture method, I took some things for granted. I thought the mapping to agile practices was more obvious than it turned out to be. After taking more customers through the approach, I realized some things are worth more elaboration. Here's some of the key things that stood out among the conversations:

Whiteboard technique. You can use the Agile Architecture method as a simple technique to quickly sketch out your solutions on a whiteboard. It's a guided process for rapid prototyping. The value is that it helps you identify hot spots for technical risks more quickly than ad-hoc or random approaches.
Hot Spots. Thinking of the cross-cutting concerns and quality attributes as hot spots seems to stick. The intersection of the hot spots and stories is a key way to drive architectural concerns.
Prioritized scenarios. The user, business, and system stories are a way to help focus and prioritize which hot spots matter most.
Mapping to agile practices. You can use the Agile Architecture method to shape your candidate architecture, as well as prioritize technical risks and guide your architectural spikes for iteration 0. For iterations 1 - N, you can use the Agile Architecture method to guide your design, implementation, and deployment inspections as well as identify hot spots in your design. You can also use it to help you periodically refactor your design to meet your objectives for your various quality attributes, such as performance, security ... etc. Most importantly, you can use the Agile Architecture method as a structured approach for addressing cross-cutting concerns and baking quality throughout the life cycle.
Just in Time Architecture. One of the most important points about the Agile Architecture method is that it's just enough architecture and just in time architecture. When you're creating your baseline or candidate solutions, it's a structured approach to help you prioritize technical risk and find the key hot spots. During iterations, it's a way to provide just in time architecture by mapping relevant hot spots against your prioritized stories.

Project Life Cycles at patterns & practices

J.D. Meier — Sun, 03 Aug 2008 06:21:23 GMT

Periodically I like to revisit our project life cycle in patterns & practices. I like to see how it's shape-shifted over the years. (Note - our project life cycle wraps our product cycle)

patterns & practices Project Life Cycle Circa 2005
Here's a snapshot of our patterns & practices project life cycle circa 2005:

I used this as a baseline to reflect against. Here are the phases, stages, and milestones:

Phases
Projects cycled through the following phases:

Planning
Design
Implementation
Stabilization
Release

Stages
Stages included:

Requirements
Specifications
Iteration 1
Iteration N
Final Test and Edit Pass
Production

Milestones
The milestones included:

Proposal Approved
Vision Scope Approved
M0 (Milestone Zero) / Specifications Approved
Technical Review and Solution Approved
Test and Edit Complete
Go / No Go
Customer Availability

Three Things That Worked Well
Here's three things that worked well with the original project cycle:

There were clear phases, stages, milestones, and deliverables, along with criteria.
The project cycle was decoupled from the product cycle. This gave management a simple frame for understanding projects. This also gave each project flexibility to choose the most appropriate software development methodology depending on the product.
There was sufficient time between key milestones to provide a frame + air-cover. This helped avoid randomizing engineering and being able to see the forest from the trees.

Additionally, the key milestones such as Vision Scope and MO were something of a ceremony and tended to include the right representation across the p&p team.

Three Things That Needed Improvement
Here's three things that needed improvement:

It was a lot of overhead for smaller projects. It worked well for larger programs (collections of projects), but it was tougher for individual projects.
It was tough to bootstrap projects. M0 and Vision/Scope could be especially tough. In retrospect, there were two key issues: 1) asking the right questions at the wrong time (premature) 2) chickens with controlling votes over pigs. (See Turning Chickens Into Pigs.)
There was too much agreement up front, with not enough ability to coarse correct in the later stages/phases (needed more agility)

Software Guidance Share

J.D. Meier — Sat, 12 Jul 2008 23:19:14 GMT

I'm testing another version of the home page on Software Guidance Share. Software Guidance Share is a perpetual work in progress. I think of it as my quick-and-dirty guidance KB for developers and solution architects. I continuously refactor information into reusable nuggets. I also test ways to browse the guidance and find relationships among the nuggets.

Here's a couple of example scenarios:

I haven't fleshed out some of the areas, but the Wiki gives me a lot of flexibility and it's easy to course-correct. In other words, it's more adaptable than adapted.

Guidance Share Sweep

J.D. Meier — Wed, 02 Jan 2008 18:48:06 GMT

One of the most important things I did while I was on vacation was sweeping Guidance Share. Guidance Share is where I consolidate my body of software engineering guidance and test user experiences. I redesigned the home page for simpler browsing and findability. It was more pain than pleasure for me, but if it helps the broader community, that's my payback.

Here's a highlight of Guidance Share:

Browsable nuggets for software performance and security
Durable, evolvable frames for security and performance (think of these as maps)
How Tos, Guidelines, Checklists and more

Guidance Share gives me a unique vantage point that I haven't been able to get any other way. The act of building it and evolving it helps me make gain new insights. It also forces me to find ways to be extremely efficient. I then try to carry these lessons over to MSDN and to help shape patterns & practices information models. I don't own the MSDN experience, but I can give input. Guidance Share helps me solidify my recommendations with living proof. It's also let's me quickly experiment with new user experiences.

My biggest lesson learned is how difficult it is to integrate information and make it useful, even when you own it. It's one thing to have a snapshot of information that's useful for a given point in time; it's another to create a stable backdrop with a firm foundation that can evolve over time. The key is factoring volatile from stable information, and enabling them to play well together.

Note that Guidance Share is under construction and there are some obviously empty areas, but it's a work in progress. It's a living knowledge base for software engineering that I periodically sweep to share the best that I've learned.

Enjoy!

Predictions for 2008

J.D. Meier — Wed, 02 Jan 2008 06:40:12 GMT

Here's a quick rundown of my take on key trends. Trends are different from fads since they're longer-lasting and more pervasive. I don't have a crystal ball or a magic 8-ball, but I have 20/20 hindsight with the customers I work with and an eye for patterns. Last year, I saw more virtualization, more agile/scrum adoption, and more distributed collaboration, as well as adoption of more social software practices in the Enterprise.

Key Trends
Here's a quick list of trends I'm paying attention to (some more pervasive than others) ...

More information overload. More ways to get lost, more ways to find what you need, more info at your finger-tips.
More focus on authority sites and authorities. Cut your info overload, by looking to people and sites you trust.
More focus on accuracy, relevancy, and timeliness. A must for social software.
More personalization / customization. One idea behind Guidance Explorer was to focus on personalization and customization.
More slicing and dicing of information. Tree-views, tag-clouds, Mind Maps, visuals. My tags, your tags, everybody's tags.
More engaging and conversational marketing over interrupt marketing. In-context, relevant, value add, and personal.
More focus on user experience. With too many choices, user experience wins. The apps that make you feel good, make you personally effective and connect with others win.
More globalization of software development. Any time, any place, anywhere, crowd sourcing, outsourcing, virtualization.
More social software in the Enterprise. Wikis, blogs, ...etc. More online consumer experience slides over to the Enterprise.
More Lean, Agile, and Scrum.
More virtualization. Virtual worlds, virtualized workspaces, Virtualized labs, virtualized hosting, virtualized workshops.
More distributed teams and remote collaboration.
More consolidation.
More specialization. When a market saturates, specialization happens. Lots more choices. Specialized devices and apps.
More Visual Studio Team System. This is The year for VSTS. With The Team Foundation Server Guide available and a new version of VSTS ... it's the year.
More Agile Security and Performance. I can help here. Most of the customers we worked with had flavors of agile practices, so we designed our techniques to be adaptable. For proven practices for security, see Security Engineering Explained.
More focus on personal development. Maybe you get what you focus on, but I see a trend here.
More principles, patterns, and practices.

Key Links for Predictions and Trends for 2008
Here's a few links I found useful:

Quick Tip
One quick tip for your trend studies -- knowing demographics helps and consumer trends tend to lead other markets so they're a good place to look. It also helps to understand the Four Stages of Market Maturity to help rationalize why you see what you see. The real value of trend watching though is anticipating and taking action, even if it just means being prepared versus surprised.

Four Stages of Market Maturity

J.D. Meier — Tue, 01 Jan 2008 02:28:33 GMT

You can tell the maturity of a market by the consumer patterns. If you know the life cycle stages of a market you can better anticipate what level of "needs" your product needs to match to be successful. (I always think of needs in stages like Maslow's hierarchy.)

The Four Stages of Market Maturity

Stage 1. Survival
Stage 2. Quality
Stage 3. Convenience
Stage 4. Customization.

From Survival to Customization
In the Autumn Special Edition of "strategy+business" magazine, Alonso Martinez and Ronald Haddock describe how a country evolves from developing nation to industrialized nation:

"As a country evolves from developing nation to indusrialized nation, the population's basic needs pass through four distinct stages. In developing countries, most of hte population is preocupied with basic survival - obtaining adequate food, shelter, and clothing. (Much of sub-Saharan Africa is in the stage right now.) As a middle class emerges, people seek greater quality in their food, housing, and clothing (This is currently happening, for example, in much of China and India.) Once a transitioning market's population can afford relatively high quality, they begin to seek convenience; they buy time-saving appliances and processed foods, and they may move closer to work. (This stage is emerging today in Eastern Europ and Latin America.) Finally, as the market graduates into the realm of developed nations, the population wants customization; with needs for survival, quality, and convenience now met, people will spend a premium (as many do in North America, Japan, and western Europe) to satisfy individual tastes and desires."

Key Take Aways
I think to successfully anticipate global market needs, you need to understand where in the stack, various consumers are. I've noticed a lot more attention on customization, particularly in social software and personal devices.

Human Shepherds and the Law of Relevancy

J.D. Meier — Sat, 10 Nov 2007 23:14:00 GMT

Yesterday, Ed helped me word a "law" that I use for important decisions and that I see show up quite a bit in a number of places. It's the law of human relevancy.

The Law of Relevancy
No matter how relevant the information is, it's more relevant with the help of the right people.

The Human Shepherd
All this law really means is that no matter how well you organize and display information, at some point, there's a glass ceiling on how much easier you can make it for somebody to find what they need. There's always a place for the human shepherd.

Usage / Examples

The obvious example is the Web 2.0 movement -- where people are the shepherds of the read/write Web. There's lots of needles in the world wide haystack and I'm glad there's people, voices, blogs there to help.
I like the pattern on the Web where sites have a live chat to use a human to help you match their info to your needs, in real time.
I like how Second Life provides the ability to "invoke a human" over just self-help and forums. (I proposed some models for "human help" in Visual Studio and as a general platform some time back I need to revisit)
There's lots of implications for an Enterprise 2.0 world, but I'll save that for another day.

A Story
In an early version of Practices Checker (a tool meant to verify your solutions against patterns & practices recommendations), we tried to figure out relevant guidance based on the type of project (Web, winForm ...), what technologies (ADO.NET, ASMX ...) you were using, ... etc. We did this automatically and generated what I considered more harm than help (it missed things that were important and created a lot of noise.) I applied the law of relevancy and argued that we'd be better off figuring out how to leverage the user's own relevancy engine and pattern-matching ability over auto-magic guesswork. We then created a tool to help smart people, rather than a "smart" tool that gets in the way.

Scenarios in Practice

J.D. Meier — Mon, 15 Oct 2007 05:21:00 GMT

Scenarios are a practical way to organize and focus your product design, development and release. (We use scenario-driven engineering in patterns & practices)

Key Benefits

Business value. You can use scenarios to evaluate business value. What pain does that scenario address? ... What opportunity does it create? ... etc.
Chunking and prioritizing. You can use scenarios to chunk up and prioritize your product. You can think of versioning in terms of releasing incremental value or scenarios.
Effective design. Walking through a set of customers scenarios and "what ifs" will help you figure out your product's most effective design. It's not a silver-bullet, but it does help make requirements more concrete, or at least put them in perspective. It also opens the door to more precise questions about user experience or engineering challenges..
Focal point for perspectives. You can use scenarios as a focal point for user experience, business and tech perspectives.
Requirements in context. You can use scenarios to put requirements in context. A requirement makes a lot more sense when you see it in action.
Architectural trade-offs. You can use scenarios to evaluate and make architectural trade-offs. You can't evaluate an architecture in a vacuum; you can evaluate against concrete scenarios. There's several flavors of scenario-based evaluations you can leverage.
Customer value. Your customers can appreciate how well you did (or didn't) address their scenario.
Tests for success. You can use scenarios as tests for success. By measuring customer effectiveness against specific scenarios, you have a way to focus your improvements.

Chunking Up a Project Using Scenarios
If you think of your product as helping a user accomplish a goal, it helps cut through the fog. You can think of your product in terms of a list of user goals, business goals and technical goals. What's the minimum set of tasks your user needs to perform with your product? That's your baseline release. What's the incremental value from there? That's how you start to shape your versions and releases.

User Experience, Business and Technical Perspectives
Using scenarios is a good forcing function to bring together the user experience, business, and technical perspectives. For the sake of example, let's say your scenario is "User views the product catalog." From the user experience perspective, you're thinking in terms of "show me a relevant list" and "don't make me wait," From a business perspective, you're thinking in terms of "support a given number of orders per hour" and "lower the total cost of ownership." From a technical standpoint, you're thinking in terms of "requests per second," "minimize resource utilization," ... etc. Well, no wonder getting software right is tough! Luckily, scenarios help you bring together and rationalize the perspectives against a common frame of reference.

Constraints Make More Sense In Context
Constraints are boundaries to operate within, or what the solution must or must not do. In software, I see a lot of generic constraints passed down as policies. When policy meets scenario, you now have a way to evaluate the effectiveness of that constraint. You can also measure whether that scenario is actually meeting the constraint. You can perform scenario-based testing against a set of scenarios with specific constraints.

Walking the Scenarios
Have you ever been sold on a great set of features, only to fall flat when you try to actually do something useful? Obviously, that's the extreme case, but it happens to me. It happens less now because whenever I go to buy something, I walk my usage scenarios. Doing a dry run against a scenario is very revealing. This approach works great on the engineering side too. It's one thing to have generic technical requirements for security or performance. It's another to evaluate a scenario and make appropriate and relevant trade-offs from a user, business and technical perspective. Suddenly, generic technical requirements no longer seem as helpful, do they? They still have their place, but when you're engineering your job is to make the right trade-offs.

Scenarios and Solutions
Given part of my job is to improve customer effectiveness on our platform, I regularly use scenarios as a backdrop for evaluation. As I've gotten more effective, I noticed shifting from features and components to scenarios and solutions is the key.

More Information

My Related Posts

Scenario Frames for Team Foundation Server

J.D. Meier — Mon, 10 Sep 2007 21:52:00 GMT

Our Scenario Frames for Team Foundation Server are available on CodePlex. We have Scenario Frames for the following:

We use scenario frames for several things:

Mapping out the problem space
Performing scenario evaluations to evaluate platform, tools, and guidance
Designing products
Scoping work

The real power of a scenario frame is that's it's a shared frame of reference. Personally, because I've seen so much benefit from scenario frames time and again, I couldn't imagine doing guidance or building a product without using scenario frames.

My Related Posts

Security Inspections

J.D. Meier — Mon, 16 Jul 2007 09:46:00 GMT

Inspections are among my favorite tools for improving security. I like them because they’re so effective and efficient. Here’s why:

If you know what to look for, you have a better chance of finding it. (The reverse is also true: if you don’t know what you’re looking for, you’re not going to see it)
You can build your inspection criteria from common patterns (Security issues tend to stem from common patterns)
You can share your inspection criteria
You can prioritize your inspection criteria
You can chunk your inspection criteria

Bottom line -- you can identify, catalog and share security criteria faster than new security issues come along.

Security Frame
Our Security Frame is simply a set of categories we use to “frame” out, organize, and chunk up security threats, attacks, vulnerabilities and countermeasures, as well as principles, practices and patterns. The categories make it easy to distill and share the information in a repeatable way.

Security Design Inspections
Performing a Security Design Inspection involves evaluating your application’s architecture and design in relation to its target deployment environment from a security perspective. You can use the Security Frame to help guide your analysis. For example, you can walk the categories (authentication, authorization, … etc.) for the application. You can also use the categories to do a layer-by-layer analysis. Design inspections are a great place to checkpoint your core strategies, as well as identify what sort of end-to-end tests you need to verify your approach.

Here's the approach in a nutshell:

Step 1. Evaluate the deployment and infrastructure. Review the design of your application as it relates to the target deployment environment and the associated security policies. Consider the constraints imposed by the underlying infrastructure-layer security and the operational practices in use.
Step 2. Evaluate key security design using the Security frame. Review the security approach that was used for critical areas of your application. An effective way to do this is to focus on the set of categories that have the most impact on security, particularly at an architectural and design level, and where mistakes are most often made. The security frame describes these categories. They include authentication, authorization, input validation, exception management, and other areas. Use the security frame as a road map so that you can perform reviews consistently, and to make sure that you do not miss any important areas during the inspection.
Step 3. Perform a layer-by-layer analysis. Review the logical layers of your application, and evaluate your security choices within your presentation, business, and data access logic.

For more information, see our patterns & practices Security Design Inspection Index.

Security Code Inspections
This is truly a place where inspections shine. While static analysis will catch a lot of the low hanging fruit, manual inspection will find a lot of the important security issues that are context dependent. Because it’s a manual exercise, it’s important to set objectives, and to prioritize based on what you’re looking for. Whether you do your inspections in pairs or in groups or individually, checklists in the form of criteria or inspection questions are helpful.

Here's the approach in a nutshell:

Step 1. Identify security code review objectives. Establish goals and constraints for the review.
Step 2. Perform a preliminary scan. Use static analysis to find an initial set of security issues and improve your understanding of where the security issues are most likely to be discovered through further review.
Step 3. Review the code for security issues. Review the code thoroughly with the goal of finding security issues that are common to many applications. You can use the results of step two to focus your analysis.
Step 4. Review for security issues unique to the architecture. Complete a final analysis looking for security issues that relate to the unique architecture of your application. This step is most important if you have implemented a custom security mechanism or any feature designed specifically to mitigate a known security threat.

For more information on Security Code Inspections, see our patterns & practices Security Code Inspection Index. For examples of “Inspection Questions”, see Security Question List: Managed Code (.NET Framework 2.0) and Security Question List: ASP.NET 2.0.” (Security Question List: ASP.NET 2.0).

Security Deployment Inspections
Deployment Inspections are particularly effective for security because this is where the rubber meets the road. In a deployment inspection, you walk the various knobs and switches that impact the security profile of your solution. This is where you check things such as accounts, shares, protocols, … etc.

The following server security categories are key when performing a security deployment inspection:

Patches and Updates
Accounts Accounts
Auditing and Logging
Files and Directories
Ports
Protocols
Registry
Services
Shares

For more information, see our patterns & practices Security Deployment Inspection Index.

My Related Posts