DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Lean Tools: Perceived Integrity

Lean Tools: Perceived Integrity

Giorgio Sironi user avatar by
Giorgio Sironi
·
Jul. 18, 12 · Interview
Like (0)
Save
Tweet
Share
7.79K Views

Join the DZone community and get the full member experience.

Join For Free

We will now explore the Lean principle "Build Integrity In" and its applications to every day coding, starting from software integrity. Integrity has two components: conceptual integrity and perceived integrity.

These two concepts resurface in many software development models over the years: for example I think they can be mapped to internal and external quality as defined by Growing Object-Oriented Software. If you're a Christopher Alexander fan, you could define conceptual integrity as the relation between form and function, and perceived integrity as the relation between form and the surrounding context. In short, conceptual integrity is related to the internal architecture of an application, while perceived integrity to its customer-facing side.

"Perceived" by people outside the team

The holy grail of software development is the perfect process for deriving a form (code and working software) from a context (the user requirements and related acceptance tests). We still work on heuristics to improve this process, with the goal of achieving the maximum perceived integrity: software that fits exactly with the mental model of the user and the assumptions he makes on the system.

For example, there are many ways we can show a map to a person and display widgets to work with it; the best images (satellite ones or road networks) and the best tools (zoom in and out, pan, directions calculation) widely depend on how the information about the user requirements is transformed into working code: if we just decide for a satellite map we are going to lose many users that wanted to refer to the map in their car. If the analysts and the product owner do not interview any potential user, or there is no geography expert in the team, the result is impoverished. If you only communicate with product-oriented people via documents, there will be a very long cycle of feedback and you will have many unanswered questions by the time your software is generally available.

This example is taken to the extreme, but the point stands: every time there is an handoff or an additional step in the road between requirements and the finished product, we risk losing information or degrading its quality. We risk to misinterpret some terms or the goal of screens; or to mix up the features that makes the application competitive from the nice-to-have ones.

Improving perceived integrity

That's the problem with a waterfall division of labor: different phases are tackled by different people, in a long pipeline (of value) that loses a bit of water at each junction. Dividing the work by user story forces a single developer to work on requirements definition, analysis, coding, testing and even releasing.

There are, however, a few tools that can improve the communication channel between the parts of the pipeline that cannot be integrated into the team (or in a single person):

  • customer-facing tests (like acceptance tests) tell us if the product is working for a client, and also document our understanding of what the system should do. Discussing over a test (written in code or Gherkin or even as an English example) is more concrete than debating over a mathematical model.
  • a glossary defines an Ubiquitous language that the customer and everyone on the team are able to speak. Currently I speak about Mobile Terminated and Mobile Originated messages and everyone in the room with me understands what we're talking about.
  • intermediate models may be useful in the road between specifications and code. However, they are costly and must be reserved for the core domain of your project and the components most difficult to get right. Many implementations of Domain-Driven Design I've seen mostly uses code as the final model to cut maintenance costs.
  • Non functional requirements can also be transmitted to the team. If a maximum response time of 2 seconds is mandatory, stories can be created to model this constraing too.

Conclusions

Agile welcomes change: even if your customers are not going to scrap half of the user stories each week, the Poppendiecks note that being able to respond to change means being able to maintain perceived integrity in the long run, even after N versions of the software have come out and half of it has been rewritten over time. Yet in many cases both types of integrity remain compromised after wide changes. We'll encounter conceptual integrity shortly, and we'll see how it is a prerequisite of perceived integrity.

Integrity (operating system) Software development Lean (proof assistant) agile

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • 10 Best Ways to Level Up as a Developer
  • Create Spider Chart With ReactJS
  • What Is API-First?
  • Key Elements of Site Reliability Engineering (SRE)

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: