Features vs Behavior
Features vs Behavior
Join the DZone community and get the full member experience.Join For Free
SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.
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.
Published at DZone with permission of Simon Brown , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.