Over a million developers have joined DZone.

Features vs Behavior

· Integration Zone

Build APIs from SQL and NoSQL or Salesforce data sources in seconds. Read the Creating REST APIs white paper, 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 brought to you in partnership with CA Technologies.  Use CA Live API Creator to quickly create complete application backends, with secure APIs and robust application logic, in an easy to use interface.

Topics:

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

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}