Features vs Behaviour

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.

About the author

Robert Annett Robert works in financial services and has spent many years creating and maintaining trading systems. He knows far more about low latency data systems and garbage collection than is good for anyone. He likes to think of himself as a pragmatist who loves technology but uses what's appropriate rather than what's cool.

When not pouring over data connections or tormenting interviewees with circular reference questions, Robert can be found locked in his shed with an impressive collection of woodworking tools.

E-mail : robert.annett at codingthearchitecture.com

Re: Features vs Behaviour

The question, in my mind, is why really an architect looks on the hollistic picture, whereas developers (if there's such a clear divide) look on the dry features. Is it beneficial? or is it only an unrealistic and spoiled perfectionism?

Re: Features vs Behaviour

@Lior: I think the 'divide' is, there are people who are or could be in the role of an architect, and people who couldn't. If you are a programmer who cares about the overall non-functional qualities of your system beyond your immediate use case, you're probably in the first group, and you think like an architect. You may not be in the role of architect in a given project, but you probably collaborate with one if it exists, or help the team to fulfill the role of an unexisting architect.

On the other hand, I know too many programmers who are not capable, or just don't care, about these concerns. These are the non-architect programmers.

Re: Features vs Behaviour

The sad (?) truth is that features are often prioritised over qualities. This is, in part, a result of not describing qualities in terms of their impact on features and vice versa. In my experience, though, it's usually due to the prioritisation process not having any representation other than end users. Everyone is a stakeholder and it's one of the architect's responsibilities to speak up for the technical qualities.

Jira can help here. By attaching templates to specific types of items you can remind developers and analysts of the non-functional aspects they should consider before starting implementation.

Add a comment Send a TrackBack