Posts

The Misunderstood Single Responsibility Principle

The Single Responsibility Principle  (SRP) is the first of the SOLID design principles that have been highly influential in software engineering since they were introduced by Robert Martin ("Uncle Bob") in 2000.  Unfortunately, this particular principle is often misunderstood.  When coupled with blind faith this can engender overly simplistic thinking and design mistakes. The principle has often been framed as "each software module should have one and only one reason to change".  And then the name seems to suggest that the module should have a "single responsibility".  That seems pretty easy to understand.  So the module should only do one thing, right?  No .  There's a different rule of thumb around that: a function should only do one thing.  Have you ever held your nose while naming a function something like "ImportData And LoadIntoDatabase".  We know this: a function should have a single, well, function . The SRP is a license to sometim

Having Career Conversations

“What’s your 3-5 year plan?  Where do you see yourself in a few years?  What do you want to accomplish?”  Unless you’re in a massively trusting setting (e.g. a spouse or best friend), who wants to answer these kinds of questions?  You might feel put on the spot.  You might feel ashamed at not having an answer or that the answer might somehow be graded.  Am I ambitious enough?  Am I humble enough?  Is it ok to say “If it were open I’d like to have your job”?  Is it ok to say I want to start my own business even though that may imply leaving the company?  Stumbling for an answer you might mutter a platitude such as “I see myself seeking gradually increasing levels of responsibility while maximizing my positive impact on the dynamics of the business...” (zzzz)  So on the receiving end, we see these conversations as challenging.  When we ask these questions of those that we mentor or manage is it any wonder that they don’t always go so well? What is the desired outcome of exploratory discu

Note to Self: All Feedback Is a Gift; and It's All Accurate

The "you" and "I" in the post are both me (yes, I'm talking to myself).   Note that, in this post, the term "feedback" denotes constructive criticism only.  I also exclude from consideration cases where the person giving the feedback is deliberately lying or where critical aspects of the feedback are built upon presumed facts that are demonstrably incorrect. Remember that: All feedback is a gift .  Imagine feedback to be a stated observation regarding a non-deterministic system that is essential for you to get anything done; but the system has no documentation, no source code, no unit tests and thus no ability to be upgraded.  In order to understand the system, all you can do is create a set of conditions, perform an operation using some input and observe the system's non-deterministic response.  Whenever you uncover problems in the system's behavior that you think will happen again, you devise workarounds.  But you don't always remember t

A Conversation That Changed My Life

I usually post tech things on my blog but before being a technologist, I'm actually a human and occasionally experience something worth sharing. And so, an anecdote... In the fall of 2013 I found myself exploring new career opportunities.  At the time, my network within the Philly community was fairly weak as I had worked in Princeton, NJ.  I was targeting VP-level Technology opportunities in the Philly area but I had no idea where to start.  I met a recruiter who had a position open.  We met over coffee and it turned out I wasn't a fit.  But he introduced me to a man that he used to work with whom he said "helps people out". This man didn't know me from Adam.  But on fairly short notice he agreed to talk with me over the phone on a Friday evening.  He had a long drive in front of him and we ended up talking for about an hour and a half.  He listened to me and made me feel comfortable.  He didn't tell me I was aiming too high like others did.  He anticipated m

Non-Production Environments: Anti-Patterns

Introduction   We all know that clean, separated environments are critical for developing and testing our software.  And yet somehow we tend to get it wrong, often.  The Continuous Delivery movement puts this at the forefront of its concerns, which is great.  So if you're headed down the CD path, chances are you are tackling or are about to tackle the "environment problem".  Because it's a tough thing to get right and because it involves up-front and continuous investment, it tends to be de-emphasized in the feature-crazed Agile world.  But unless you're just doing a proof-of-concept, not solving the environment problem will slow you down, hurt quality and become harder to fix over time.  There are a few anti-patterns that I see over and over: Not giving proper attention to the data tier(s) of the stack (e.g. relational database, NoSQL database, text/search database, file systems used for storage, etc.) Not extending environments "all the way out&quo

Dig a Little Deeper

Be sure to separate symptoms of a problem from the problem itself.   This can sometimes be harder than it seems.   Sometimes the problem is a few layers below the surface.   For example, assume you get the following issue reports and feature requests: 1.      Please add a button to all list screens to export data to Excel. 2.      Whenever running a query that returns a lot of data (e.g. 10K rows) the list screens take a long time to return. 3.      We’d like to be able to run very basic (read-only) queries by linking to some tables through MS Access.   But in order to do that we need an Oracle client installed on our machine.   We also need a username/password for the database. 4.      Please add “week ending” and “month” to the return fields for all list screens. On the surface these seem like simple, disparate problems to be solved.   So you might come up with solutions like this: 1.      “Sure – we can add an export button”. 2.      “Hmmm – we’ll

A Response to the Reactive Manifesto

The Reactive Manifesto published by Typesafe is getting a great deal of attention in the Scala community.  A new version was posted yesterday and I could not help but reply with criticism that has been bothering me for some time.  The Reactive Manifesto appears to be a thinly veiled way to back into Akka being the cure for all ills.  I think this is an irresponsible message especially from a company like Typesafe that is guiding a great number of people that are just venturing into Scala.  One sure way to hurt the Scala community is to offer the advice that one should adhere to a reference architecture that is best applied for only a certain set of problems.  My comment/reply to the Manifesto appears below in its entirety.  I hope that, at a minimum, it stimulates some thought for those that were intending to jump into the Akka pool without fully understanding why. Jonas: I am the VP of Engineering at LeadiD a tech startup based in Ambler, PA. We are building out a large, compl