Non-functional requirements are important yet often forgotten

abolla_18076_sm

Most software professionals in my experience lapse into talking about “requirements” while meaning only functional requirements. We seem to forget that there are also non-functional requirements, and that non-functional requirements are usually just as important as functional requirements to the end user or customer. Sometimes the non-functional requirements are more important.

Just to set some context, I would describe “functional requirements” as software requirements that . . .

Consider wrapping properties maps or lists in their own class

A common pattern in Java is to use a List, Map, Set, or other collection object when faced with keeping a variable number of properties about an object. Sometimes this is seen in obvious anti-patterns like holding URL parameters in a map. Other times there is a legitimate reason. For example, the book Head First OO Analysis and Design illustrates modeling an unknown number of guitar features for items in a guitar shop inventory with a map holding values like {fretboard = maple, tuners = locking}. The available information to be held in this map varies depending on what the manufacturer has provided about a particular item. Continue reading “Consider wrapping properties maps or lists in their own class”

volcanicpillar_crop

New around the web: The Perfect Company and A Little Architecture

This came up in my Twitter, and I’ve never read the blog before, but the post is a good one.

Whatever you do, do not join a company that values something you don’t believe in. Don’t fool yourself into thinking you can change it, or that you can adjust to it. It’s going to suck.

http://blog.capwatkins.com/the-perfect-company

And then, a new one from Uncle Bob:

Woe is the architect who prematurely decides on a database, and then finds that flat files would have been sufficient.
Woe is the architect who prematurely decides upon a web-server, only to find that all the team really needed was a simple socket interface.
Woe is the team whose architects prematurely impose a framework upon them, only to find that the framework provides powers they don’t need and adds constraints they can’t live with.

http://blog.cleancoder.com/uncle-bob/2016/01/04/ALittleArchitecture.html

Is business logic hiding in your data?

Databases are for data. Business logic is usually best stored in readable code. The main reason that it is not a good idea to store business logic in the database is that databases resist change, and business logic changes all the time. A good programming language coupled with a well-engineered application design allows a lot of flexibility for that change to happen on top of the database.

56021_peek-window_sm Continue reading “Is business logic hiding in your data?”