Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Features vs Behavior

DZone's Guide to

Features vs Behavior

· Integration Zone
Free Resource

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA Technologies.

Originally authored by Robert Arnett

Does your software development process exclude solving architecture and system issues?

I've recently had a bug I raised with a third party software supplier downgraded from high to low importance. No one likes having their bugs downgraded (it probably shows you what a nerd I am by taking this personally) but what surprised me was the reason. The bug was causing lots of misleading errors to be reported but the bug was deemed to not affect core 'functionality' as the feature worked from an end user's perspective. However it has a negative effect on our ability to operate the software system.

This seems to be one of the big differences between software developers and software architects. Software developers/programmers think in terms of features and a feature tends to be defined in terms of cause and effect e.g. a user clicks on a button and the system responds. A defect or bug is simply when the system does not give the response as defined by the specification.

An architect should consider the holistic behaviour. Not only thinking about a resultant action but the complete behaviour and life-cycle of the action. From simple (and measurable) items like timings (latency, response etc) to more complex system behaviour such as auditing, logging, replication etc.

Most software development processes revolve around features. Therefore when a bug is raised it HAS to be registered against a feature. This is then passed to a developer who either rejects it as 'working' or downgrades it as not being core or having a 'work around'. However the work around might be unacceptable such as waiting longer, bad logging/auditing or a side effect on a completely different part of the system.

In my experience it is rare for a development process to consider system or architecture issues.

Does your software development process allow you to raise and track non-functional issues and how do you do this? Do tools (such a JIRA) help or hinder with this? These issues will cut across many features - should they be raised against a set of features or have a single bucket that they get put in? Most importantly, how can I get my bug upgraded when they have a feature based bug reporting process?!

As a side note it appears to me that Simon Brown's and Robert Martin's debate is partially about the differential between product features and system behaviour.

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

Topics:

Published at DZone with permission of Simon Brown, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}