The question of how much design to do up-front on a project is an engaging conundrum. Too much design often results in excess complexity and wasted effort. Too little design results in a poor architecture or insufficient system structures which require expensive rework and hurt more in the...
The question of how much design to do up-front on a project is an engaging one. Too much design often results in overkill, complexity, and wasted effort. Too little design results in insufficient system structures that require later rework, additional complexity, and wasted effort.
One of software development’s greatest challenges is combining business needs with technical abilities to build products that customers want. Many development methodologies attempt to achieve this, but Nir Szilagyi and Janarthanan Eindhal think that few connect the dots as well as...
Nir Szilagyi, eBay, Inc. & Janarthanan Eindhal, eBay, Inc.
Research into your users’ personas can provide deep insights into their needs and validate your product design. This research doesn’t have to take months; it can often be done in two weeks, during sprint 0. Unfortunately, many companies using agile methods don’t invest in personas and a...
Tired of the claims that Scrum, XP, and kanban don’t scale beyond a few teams? Overwhelmed by management’s resistance to the organizational changes needed to really follow agile principles? Concerned with the lack of proven practices required to scale agile methods to the next level?
In agile projects, design ideally "emerges" over the course of development. However, if teams primarily focus on independent user stories, they risk losing sight of the product's vision and the integrity of well-thought-out architecture. Ken Kubo shares techniques he's used to improve the chances that a product's design will emerge into a cohesive and coherent architecture that serves its customers for many years. Join Ken to find out how you can incorporate contextual design principles and simple, visual techniques as part of his "A-Little-Before-Its-Time Design" framework. You can add these practices into your agile workflow to maintain a shared team understanding of your product's vision and the system's emerging design. Ken believes that you can only realize all the promises of agile development with a clearly and constantly communicated product vision and a set of architecture goals.
Mock objects are simulated objects that mimic the behavior of real objects in controlled ways. Because many code modules interact with external entities-things like databases, networks, file systems, third-party frameworks, and even the clock-these entities often cause us big-time trouble during unit testing. These entities can slow down our unit tests, produce unpredictable results, and have dangerous side effects. The best unit tests are decoupled from these external entities. Rather than try to control the entities, you can create mock objects to simulate their functionality. With a tangible example in the form of a short play, Rob Myers introduces mock objects and provides a brief history of their "relatives"-stubs and fakes. Then, with an animated, nearly-worst-case example, Rob presents code he developed to "mock out" nasty dependencies and create safe, predictable unit tests.
Although usability and user experience may seem synonymous, they are separate and much different concepts. While usability is well defined in standards, UX has no agreed upon definition because it relates to a more nebulous attribute-user satisfaction. Both are, however, key ingredients for successful system deployment. Because they don’t know how to measure and evaluate UX, many teams ignore this important attribute until the end of development. Philip Lew discusses how to model both usability and UX by breaking each attribute down into measurable characteristics-learnability, user effectiveness, user efficiency, content quality, user errors, and more. Phil shows you how to derive measurements and metrics that your development and team can employ to benchmark, analyze, and improve both usability and UX.
As developers, we've created heuristics that help us build robust systems and employed test-driven development (TDD) to improve code design and counter instability. Yet object-oriented development principles and TDD have failed to gain traction in the database world. That’s because database development involves an additional driving force-the data. Max Guernsey shows how to treat databases as objects with classes of their own-rather than as containers of objects-and how to drive database designs from tests. He illustrates a way to give these database classes the ability to upgrade old data without introducing undue risk. Max also shares how to apply good object-oriented design principles to database classes and how to enforce semantic connections between databases and clients.