This book presents the SigniFYI Suite of conceptual and methodological tools, designed to uncover meanings inscribed in software, their origins, intent and consequences to identify and trace correlating patterns; from software design and development to software use and experience. Based on the study of Semiotic Engineering, the book advances the e study of Human-Centered Computing (HCC), inviting professionals, researchers, teachers and students to reflect upon how subjective and cultural values manifest themselves through software models, programs and user interfaces. The authors weave a mesh of technical, theoretical and philosophical considerations of what it means to build and use software, exploring what we (professionals and non-professionals) mean by the pieces of software we design and develop, as well as what pieces of software mean to end-users and others. Explicitly dedicated to software designers, developers and users, Software Developers as Users is a provocative view of socio-technical communication in the digital age.

Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software. The best way to build software that meets users' needs is to begin with "user stories": simple, clear, brief descriptions of functionality that will be valuable to real users. In User Stories Applied, Mike Cohn provides you with a front-to-back blueprint for writing these user stories and weaving them into your development lifecycle. You'll learn what makes a great user story, and what makes a bad one. You'll discover practical ways to gather user stories, even when you can't speak with your users. Then, once you've compiled your user stories, Cohn shows how to organize them, prioritize them, and use them for planning, management, and testing. User role modeling: understanding what users have in common, and where they differ Gathering stories: user interviewing, questionnaires, observation, and workshops Working with managers, trainers, salespeople and other "proxies" Writing user stories for acceptance testing Using stories to prioritize, set schedules, and estimate release costs Includes end-of-chapter practice questions and exercises User Stories Applied will be invaluable to every software developer, tester, analyst, and manager working with any agile method: XP, Scrum... or even your own home-grown approach.

Work practices and organizational processes vary widely and evolve constantly. The technological infrastructure has to follow, allowing or even supporting these changes. Traditional approaches to software engineering reach their limits whenever the full spectrum of user requirements cannot be anticipated or the frequency of changes makes software reengineering cycles too clumsy to address all the needs of a specific field of application. Moreover, the increasing importance of ‘infrastructural’ aspects, particularly the mutual dependencies between technologies, usages, and domain competencies, calls for a differentiation of roles beyond the classical user–designer dichotomy. End user development (EUD) addresses these issues by offering lightweight, use-time support which allows users to configure, adapt, and evolve their software by themselves. EUD is understood as a set of methods, techniques, and tools that allow users of software systems who are acting as non-professional software developers to 1 create, modify, or extend a software artifact. While programming activities by non-professional actors are an essential focus, EUD also investigates related activities such as collective understanding and sense-making of use problems and solutions, the interaction among end users with regard to the introduction and diffusion of new configurations, or delegation patterns that may also partly involve professional designers.

The topic of the research reported here is direct user participation in the task-based development of interactive software systems. Building usable software demands understanding and supporting users and their tasks. Users are a primary source of usability requirements and knowledge, since users can be expected to have intimate and extensive knowledge of themselves, their tasks and their working environment. Task analysis approaches to software development encourage a focus on supporting users and their tasks while participatory design approaches encourage users' direct, active contributions to software development work. However, participatory design approaches often concentrate their efforts on design activities rather than on wider system development activities, while task analysis approaches generally lack active user participation beyond initial data gathering. This research attempts an integration of the strengths of task analysis and user participation within an overall software development process. This work also presents detailed empirical and theoretical analyses of what it is for users and developers to cooperate, of the nature of user-developer interaction in participatory settings. Furthermore, it makes operational and assesses the effectiveness of user participation in development and the impact of user-developer cooperation on the resulting software product. The research addressed these issues through the development and application of an approach to task based participatory development in two real world development projects. In this integrated approach, the respective strengths of task analysis and participatory design methods complemented each other's weaker aspects.

The topic of the research reported here is direct user participation in the task-based development of interactive software systems. Building usable software demands understanding and supporting users and their tasks. Users are a primary source of usability requirements and knowledge, since users can be expected to have intimate and extensive knowledge of themselves, their tasks and their working environment. Task analysis approaches to software development encourage a focus on supporting users and their tasks while participatory design approaches encourage users' direct, active contributions to software development work. However, participatory design approaches often concentrate their efforts on design activities rather than on wider system development activities, while task analysis approaches generally lack active user participation beyond initial data gathering. This research attempts an integration of the strengths of task analysis and user participation within an overall software development process. This work also presents detailed empirical and theoretical analyses of what it is for users and developers to cooperate, of the nature of user-developer interaction in participatory settings. Furthermore, it makes operational and assesses the effectiveness of user participation in development and the impact of user-developer cooperation on the resulting software product. The research addressed these issues through the development and application of an approach to task based participatory development in two real world development projects. In this integrated approach, the respective strengths of task analysis and participatory design methods complemented each other's weaker aspects.

It’s been said that software is eating the planet. The modern economy—the world itself—relies on technology. Demand for the people who can produce it far outweighs the supply. So why do developers occupy largely subordinate roles in the corporate structure? Developer Hegemony explores the past, present, and future of the corporation and what it means for developers. While it outlines problems with the modern corporate structure, it’s ultimately a play-by-play of how to leave the corporate carnival and control your own destiny. And it’s an emboldening, specific vision of what software development looks like in the world of developer hegemony—one where developers band together into partner firms of “efficiencers,” finally able to command the pay, respect, and freedom that’s earned by solving problems no one else can. Developers, if you grow tired of being treated like geeks who can only be trusted to take orders and churn out code, consider this your call to arms. Bring about the autonomous future that’s rightfully yours. It’s time for developer hegemony.

While there is a lot of appreciation for backend and distributed systems challenges, there tends to be less empathy for why mobile development is hard when done at scale. This book collects challenges engineers face when building iOS and Android apps at scale, and common ways to tackle these. By scale, we mean having numbers of users in the millions and being built by large engineering teams. For mobile engineers, this book is a blueprint for modern app engineering approaches. For non-mobile engineers and managers, it is a resource with which to build empathy and appreciation for the complexity of world-class mobile engineering. The book covers iOS and Android mobile app challenges on these dimensions: Challenges due to the unique nature of mobile applications compared to the web, and to the backend. App complexity challenges. How do you deal with increasingly complicated navigation patterns? What about non-deterministic event combinations? How do you localize across several languages, and how do you scale your automated and manual tests? Challenges due to large engineering teams. The larger the mobile team, the more challenging it becomes to ensure a consistent architecture. If your company builds multiple apps, how do you balance not rewriting everything from scratch while moving at a fast pace, over waiting on "centralized" teams? Cross-platform approaches. The tooling to build mobile apps keeps changing. New languages, frameworks, and approaches that all promise to address the pain points of mobile engineering keep appearing. But which approach should you choose? Flutter, React Native, Cordova? Native apps? Reuse business logic written in Kotlin, C#, C++ or other languages? What engineering approaches do "world-class" mobile engineering teams choose in non-functional aspects like code quality, compliance, privacy, compliance, or with experimentation, performance, or app size?