Showing posts from 2014

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

Build Upon Rock: Understand the Business Need

Because software developers are in the business of delivering solutions our thinking and discussions with business owners tend to be solution-oriented. It’s not uncommon to hear things like this from business owners: “I really need a new column added to the F105 report – the total processing time.” “I need a new screen that tracks inventory.” It’s also not uncommon for developers to listen to business owners talk about their issues and jump to well-known solutions and say things like: “What you need is a CRM system.” “The F109 screen will take of everything you need. I’ll show you how to use it.” Thinking about solutions is not a bad thing but it can lead to mistakes if the business problem is not framed properly. You can tell that you’ve framed a business problem properly when its description has nothing to do with a system, per se. Take the case of adding a column to the F105 report. Rather than respond – “ok – we’ll get right on that,” start by getting to the underl

Software Development Methodology Patterns

“I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.” -- The Oath of Non-Allegiance, Alistair Cockburn, Co-Creator of the Agile Manifesto One of my current interests is enumeration of common patterns within software development methodologies that might become part of a standard toolkit. I do not assume that all patterns apply equally well in every circumstance. I reject the idea that there is a silver-bullet methodology that will work for all types of projects – even considering that one might be defining patterns to be used at a single company with a single culture. The idea that strict methodologies apply well to all projects in all companies I reject with even more vehemence. So if each situation has some uniqueness, should we reject methodology altogether? Of course not. But rather than assume a monolithic prescriptive methodology can