How to slow down and go faster

In my previous article please don’t organize for speed, I shared this paradoxical quote from Cisco’s Scott Cherf:

To go faster, slow down. Everybody who knows about orbital mechanics understands that.

Say what? Slow down to go faster?
What do you think Cherf is talking about? Not rushing? That’s probably most people’s first thought. I bet most of us have had the experience of rushing to get a task done and screwing something up in a way that makes us have to go back and do the work over.

tides_30709_md

Another possibility is that he means we should follow a plan . . . (read more)

Why I defactor as much as I refactor

What is defactoring?

Defactoring is actually refactoring, but it looks and feels wrong because it seems like reverse refactoring. Defactoring is refactoring code toward a seemingly worse state, such as one with duplicate code and code that has moved from higher to lower level abstractions. I once shied away from defactoring, feeling like I must be committing some crime, but now I embrace it, under certain circumstances.

A description of how an apple grows from a flower. From Hilgard, E. W. and W. J. V. Osterhout Agriculture for Schools of the Pacific Slope (New York, NY: The MacMillian Company, 1910)
A description of how an apple grows from a flower. From Hilgard, E. W. and W. J. V. Osterhout Agriculture for Schools of the Pacific Slope (New York, NY: The MacMillian Company, 1910)

Why would I want to defactor?

One reason to defactor code is . . .

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