Custom Software Development is dead

Haven’t you heard? Custom Software Development is dead. No one should have any reason to do Custom Software Development unless you are building a product to resell to clients. The creation of a novel solution created to address a specific client or problem is definitely passé.

Custom Software Development is much too risky. It is much less risky to take an existing product that has been created by an established vendor and just configure it to fit your needs. This is far less risky and quicker.

Custom Software Development is too costly. With our expert outsourced development team in some far way land, we can quickly develop software with inexpensive resources that will do everything you require.

Sound Familiar?

The truth is that Custom Software Development is not dead. Custom Software Development just needs to hire better marketing. For the longest time the product vendors have been selling Fear, Uncertainty, and Doubt about Custom Software Development.

To be honest, the really bad stories of projects going wrong are usually about product implementations. I mean the really bad ones. Not the 100% over budget ones, but the 300%-400% over budget ones with overruns of 10’s of Millions of dollars are usually always product implementations.

Most importantly, all the really terrible experiences of client satisfaction are with product implementations. Although Custom Software Development projects can have schedule and budget issues, I rarely hear that the Custom Software Solution doesn’t meet their needs. (When I say rare I mean like never)


So why do corporations continue to choose products instead of Custom Software Development? I believe it comes down to four reasons:

1) Corporations place less emphasis on a solution meeting their client’s needs than meeting the budget – This is a sad to say, but the real focus is on delighting the accountants and not the end users and clients. If I had a nickel every time I heard the phrase ‘good enough’ on a product implementation project, I’d be sunning myself on a private island in the Caribbean.

2) Product companies avoid getting into detailed requirements until after the initial sale – This is probably the biggest reason behind product selection. Early on the discussion are high level and it appears that the product is a 70-80% match of requirements. The decision is made to proceed and it is agreed that we will flesh out the detailed requirements during the project. Then during the project, you determine that there is only a 20-30% fit and more extensive work is required. Once that is determined it is far too late to change the approach.

3) Existing Products have inherent credibility and confidence – When faced with questions from boards and executives, the use of a product that is known in the marketplace does provide confidence. It also doesn’t hurt to say to executives you are offshoring development to save money. Both of these facts appeal to our human tendencies to never buy something first and to only buy something on a sale.

4) Corporations lack confidence in Information Technology – Many corporation lack confidence in their Information Technology departments and usually have a few experiences of Custom Software Development that has gone badly. Product Implementations seem to be the solution to both of these issues. Outsourcing the development to an independent Custom Software Development firm seems even riskier.

So what can we do as believers in Custom Software Development?

We can do promote the benefits of Custom Software Development ; You get exactly what you need and have full control over the solution going forward.

I heard early in my career that products are best used for the supporting and expense side of your business and Custom Software Development is best used for the core business and revenue generation side of your business.

If you don’t have full control to delight and serve your clients you probably won’t be in business long.

If you are thinking of making a product decision, ask your self if it involves the revenue side of the business. Then investigate how difficult it would be to materially change the product in the future.

If these change are difficult, your product may only be capable of generating new revenues for the product vendor.


When focusing on Minimum Viable Product is the wrong thing to do #Agile #MVP


There isn’t too many things more sacred than Minimum Viable Product in the Agile circles. Maybe Planning Poker, Automated Testing, and Continuous Integration. But usually Minimum Viable Product is also right up there. What if I told you that focusing on Minimum Viable Product is sometimes the wrong thing to do? Would I be branded a heretic?

Well it is – sometimes.

Client Focus

I sometimes find that we in the Agile community are falling into the old traps that haunted the traditional Software Development Professional – the fact that we know what is best for the client. I see comments like we shouldn’t create any documents or create any estimates because they are waste. Usually these positions are written from the point of view of the Software Development team. But we as developers may define value and waste differently than our clients. We need to understand the context of the project we are in and the situation the client is in and apply our processes accordingly.

For some clients not creating documents may be a waste as they will need to create them for regulatory purposes and it may take them longer to create them after. (In addition to being more error-prone) For some clients, estimates may provide them great value in their forecasting and budgeting process. So while we may think that creating estimates in wasteful, the clients may not share the same view. Ultimately, their viewpoint is the one that matters if we want to be client focused and remain in the service industry.

Our job as Software Development professionals is to provide our expert opinion and highlights the impacts of the decision to the client. If we can’t convince the client of the value of our position, then our position could not have been a strong one to start with.

Our job as Software Development Professionals to to provide all the information to the clients so they can make the most well-informed decision possible. Not to decide for them. Ever.

Minimum Viable Product

So where does that leave us with Minimum Viable Product? How could organizing the project in a way that you could go live during the project be wrong?

Well, what if going live early has no value to the client?

In the diagram above, what if the client definition of value is only realized by being able to transport a family of 5? Being able to structure a project to continue to deliver Minimum Viable Products comes with a cost. If you look at the example above, you can see that so each step up in the viable product chain, we need to swap out some frameworks and functionality for other frameworks and functionality. Structuring a project in this way doesn’t come without a cost.

Now there are many great technical reasons why to want to structure a project focusing on a chain of Minimum Viable Products. They help to address risk and provide lessons learned to improve the product and project as you go along. But don’t assume that it is always what the client wants, needs, or values. In exceptional circumstances, the extra effort to structure a project focusing on Minimum Viable Product may actually be most wasteful that structuring the project in a traditional way.

There might be a series of Minimum Viable Products that could be created to address technical risk, but not to provide any early client value. Perhaps it might be just one prototype early on to address new technology. The important thing is don’t assume it has value for the client.


We must always remind ourselves that the processes and methods we use must return more value for the client than other options and not just fall into the habit of executing every project using all the Agile tools in the tool belt.

After all, isn’t that what got us in the Detailed Work Breakdown Structure, Big Design Up Front mess before?




A case for Contingency #NoEstimates

It seems like everyone has a different view of the role that contingency should play on projects. While some recommend removing it so as to not inflate the cost of features, others feel it is a critical element in the estimation of the project. Some people feel it is best to hide it away in the features themselves, while others like it explicitly separated for clear communication.

One thing is clear to me after many projects that have gone well and poorly. Contingency is required. Contingency is required to portray a realistic image of how the project will go. While many people try to remove Contingency to not inflate the cost of a project, it actually reflects reality.

Contingency is the cost factor of likely issues that the project will hit based upon the experience of the team and company executing the project. To remove contingency would be ignoring the past.

Even the noble attempt to remove contingency and work solely with feature velocity so that the team and the client can jointly work on the prioritization of features is misplaced. Removing that contingency will change the decisions made by the business early on. Without the contingency , the client may feel that they will get more done and will add more scope. Then once issues start being encountered, it becomes very apparent that the client won’t get everything they need because they added items early on based on the perceived velocity and lack of need of contingency.

For example, Let us say we have 100 features that we need to accomplish and based on the first month we determine we appear to have a velocity of 20 features a month. The project is required to go live in 6 months. This appears to be a solid 5 month project. Early on in the project we encounter 12 features that the client would also like to have. So we add them since we have an extra month. What we find a couple of months in is our velocity is really 16 not 20. (as we encounter some more difficult features) Now we determine we will only be able to complete 96 out of the 112 features we have. Although we are working in priority sequence, there probably are some features that the client can’t go live without.

We have a pickle. All because we didn’t use contingency to reserve budget and schedule based on realities.

To me No Estimates sometimes feels like doing Physics problems without friction. While the equations hold and produce logical results, they don’t reflect reality. And once you add friction to the equations, the change in the results can be quite dramatic. If No Estimates work for you, then you are probably more in the product rather than project space and I’m envious. 🙂

But for the most part most of us need to deal with friction.

While No Estimates is intriguing, the removal of the analysis and incorporation of contingency is dangerous and can be deadly. While past velocity is an important factor, future planning and learning from the past is equally important. To manage mathematically based on past history is overlooking one very key factor – prior projects and experience. As we know most of the issues happen later on the projects. Contingency isn’t linear. Planning with only velocity requires contingency to be linear. In reality, we adapt to early velocity and make scope decisions based on that. They when issues hit that require contingency, it is no longer there as we have made decisions based upon what we think we can do based on past velocity.


Contingency isn’t evil or bad. It doesn’t inflate the cost of a project. If anything, it is the one thing that takes a paper plan and makes it real. Leave it out at your own peril.

#SAP, Breaking Data, and Re-enabling #SQLServer Database Referential Integrity Constraints #Microsoft #FTW

Many times as Data professionals we no longer have full control over the quality of data in the source systems. I am discussing SAP in my example, but I could have easily mentioned PeopleSoft, SalesForce, or a number of other purchased solutions. Usually those solutions are purchased and then we are tasked with maintaining those environments and also extracting data from those environments to be incorporated into a Business Intelligence corporate solution.

Our issue is one somewhat of our own choosing as well. We want to enforce integrity and constraints at a greater level than what was intended and specified in the purchased applications. This may be for a variety of reasons including that the business never specified it as a requirement. It may also be that the purchased application was never built to handle that level of integrity.

To be clear, this isn’t a complaint but more a reflection of reality. We as Data professionals are going to receive data that is not as consistent and complete as we as Data professionals want it to be. (I purposely did not state ‘require’ as there could be a discussion of what is truly required) So what are we to do?

The Problem

Typically we end up extracting data from these purchased applications and load them into a consolidated database. This database can be either a relational or dimensional database. We also typically need to cleanse the data we are loading so load the business can report on the data in a clear and consistent manner.

The challenge is what we do with data that we cannot load in a consistent manner. We really have two options; modify the data or reject it outright. Although there are many types of inconsistent data we may need to correct, I will limit my discussion to data that links tables together. Typically we define Referential Integrity or Foreign Keys constraints to ensure that the data to link tables are valid so that reports and queries return correct results.

Possible Solution

When we have more control over the quality of source systems, I usually see the solution embedded in the Extract, Transform, and Load (ETL) solution that extracts and loads the data into a corporate database.  This is because the data issues will be more known, of lesser frequency, and the data issues are things we can correct ourselves. In this type of solution, the Foreign Key constraints are always enabled and the  ETL solution validates all the data values before trying to insert the data in the database. Any errors that are encountered will result in the data being changed or rejected and an error written to a log file.

There are two majors issue with this approach:

1) Performance – The look-up to validate all Foreign Keys row by row can cause the process to run slower. It can eliminate a performant two step approach where some of the fields can be set in a subsequent SQL Update statement. (Depending on the column’s Nullability) It can also prevent the use of some bulk load methods in SQL Server Integration Services.

2) Availability – If major data issues are encountered, the data issues may prevent the data load from continuing and may affect the availability of the database.

Our Solution

Since we are loading data from multiple external providers, we designed a different solution.

Although we have Foreign Key constraints on the entire database, they will be disabled during the load. (and during the week) We will enable them every Sunday to validate the data loaded has not broken integrity rules. If we find we cannot re-enable any constraint, we will email the Data Team informing them of the offending constraint for investigation. If all Foreign Key constraints can be re-enabled, we will inform the Data Team of the success and disable them again.

We could also do this re-enabling nightly if we start to encountered more frequent data errors.

In this manner, we are in a better position to react to data outside of our control and load the data as quickly as possible.

Our SQL Server Solution

A couple of things to note about our SQL Server solution. Frequently I see the solution to re-enable all constraints use the sp_msforeachtable stored procedure. A sample of how to do this is listed below:


This solution is virtually useless you can guarantee all your constraints can be re-enabled without failure. If one constraint fails, it will stop the process. Not good.

To accommodate the ability to re-enable all constraints even when errors are encountered we created our own processes to disable and re-enable our constraints using a cursor.

Here is the disable constraints SQL

DECLARE @disable_sql NVARCHAR(255)

CASE fk.is_disabled
INTO temp_disable_constraints
FROM sys.foreign_keys AS fk
INNER JOIN sys.objects AS o ON o.[object_id] = fk.[object_id]
INNER JOIN sys.objects AS po ON po.[object_id] = fk.parent_object_id
INNER JOIN sys.objects AS ro ON ro.[object_id] = fk.referenced_object_id
AND rccu.TABLE_SCHEMA = SCHEMA_NAME(po.[schema_id])
INNER JOIN sys.index_columns AS ric ON ric.[object_id] = fk.referenced_object_id
AND ric.index_id = fk.key_index_id
AND ric.is_included_column = 0
INNER JOIN sys.columns AS rc ON rc.[object_id] = fk.referenced_object_id
AND rc.column_id = ric.column_id

DECLARE disable_cursor CURSOR for
FROM temp_disable_constraints

OPEN disable_cursor
FETCH NEXT FROM disable_cursor INTO @disable_sql


PRINT @disable_sql

EXEC sp_executesql @disable_sql
FETCH NEXT FROM disable_cursor INTO @disable_sql


CLOSE disable_cursor
DEALLOCATE disable_cursor
DROP TABLE temp_disable_constraints

And our re-enable constraint SQL:

DECLARE @enable_sql NVARCHAR(255)

CASE fk.is_disabled
INTO temp_enable_constraints
FROM sys.foreign_keys AS fk
INNER JOIN sys.objects AS o ON o.[object_id] = fk.[object_id]
INNER JOIN sys.objects AS po ON po.[object_id] = fk.parent_object_id
INNER JOIN sys.objects AS ro ON ro.[object_id] = fk.referenced_object_id
AND rccu.TABLE_SCHEMA = SCHEMA_NAME(po.[schema_id])
INNER JOIN sys.index_columns AS ric ON ric.[object_id] = fk.referenced_object_id
AND ric.index_id = fk.key_index_id
AND ric.is_included_column = 0
INNER JOIN sys.columns AS rc ON rc.[object_id] = fk.referenced_object_id
AND rc.column_id = ric.column_id

DECLARE enable_cursor CURSOR for
FROM temp_enable_constraints

OPEN enable_cursor
FETCH NEXT FROM enable_cursor INTO @enable_sql


EXEC sp_executesql @enable_sql

PRINT ‘ERROR–>’ + @enable_sql
FETCH NEXT FROM enable_cursor INTO @enable_sql

FETCH NEXT FROM enable_cursor INTO @enable_sql


CLOSE enable_cursor
DEALLOCATE enable_cursor
DROP TABLE temp_enable_constraints


This solution has provided us the flexibility to load our data as efficiently as possible and validate our Foreign Key relationships on a recurring basis. It also minimizes the chance that our load process will stop mid-stream. Did I mentioned this is a key requirements as we are loading data into the Data Warehouse every 60 minutes? 🙂

I was initially concerned with how long it would take to re-enable the constraints, but it only takes 75 minutes to re-enable 616 Foreign Key constraints on a 1.1 Terabyte database. Thanks Microsoft!

Now that we have this process we also plan to use it on large software deployments just to ensure to major data issues were introduced with the deployment as well.

Birth of #Agile #Agile2014

Reading through all of the Agile 2014 tweets, my memory flipped back to my university years where I consider the seeds of Agile were sown. Although I am sure people at that time didn’t think that was the CASE. (pun intended)

I was taking my Advanced System Analysis course and the final chapter was on CASE tools. If you want a refresher, the wikipedia page is actually quite good.

I remember at that time in the late 80’s there was major discussion/movement on code generation and CASE tools. I guess it was the professions response to all the challenges with Software Development at that time. We had challenges completing projects successfully and within our estimates, so the CASE tools were going to ride to the rescue and generate all the code once we got all the requirements specified. In that way we would remove all the challenges and problems with the troublesome development activities. Which I guess were identified as the problem. If anything, this was the last gasp of the big requirements up front movement. If anything, these CASE tools required even more detailed requirements up front than were required before. A proliferation of modeling tools arose out of this movement to greater and lesser degrees of success. But thankfully none of these tools really provided an answer to the problems.

In my limited use of CASE tools, I was amazed with the amount of work required to define the requirements to be able to generate code. And then it seemed that unless the code was totally mundane, there would always be issues with the code. And don’t get me started on the performance of the code.

Two Solutions

What I thought was interesting was that I saw two solutions arise out of the CASE rubble.

1) Off-Shoring – In the spirit of sub-optimization, this solution followed in line. If we can’t design tools to generate the code automatically, lets figure out a way to ship the code creation to the cheapest possible resources. In many ways, this was a solution in-line with the principles of CASE. We need to create a detailed specification document that we can then take and generate code from,  either by algorithm or people.

2) Agile – although we didn’t call it Agile at the time, the other movement that arose was a recognition that sub-optimizing the development activities was the wrong approach. What we needed was an integrated, cross-functional team, not more requirement documents. We also needed to deliver more frequently to the end client and work side by side with them. This was the absolute opposite of what was typically envisioned with the CASE solutions. In hindsight, I really feel that this was the start of many of the flavours of Agile. (although they wouldn’t officially should up on the scene until years later)


What I find most interesting is when I look back, the CASE movement was all about trying to solve a problem with more and more technology. Which we know hardly ever works. Now there is additional technology that makes Agile solutions possible, but at its heart it is a system with less technology not more. It is about communicating and working together to solve a business problem. Whether we be business people, analysts, developers, or yes, even project managers.

If I only had the foresight back them to buy stock in 3M for all the stickies that the industry would successfully use over the next decades, I would be a rich man.

Rest in Peace CASE, Long Live Agile.


Temporary Solutions can be more permanent than Strategic Solutions

I know we have all been there before. We get an urgent request that flies across our desk talking about a temporary and tactical solution we absolutely need to do. It is followed by explanations on why it is required and apologies for the non-standard solution. Usually it is required due to some last-minute sale or promise made by C-level person.

And then we get the Software Development equivalent of “Of course, I’ll call you tomorrow…”

“It is only a temporary solution, we won’t have to live with the solution for long”

The Two Truths

There are two undeniable truths about this situation:

1) It is required

There are many business solutions that are not pretty or perfect. Many business solutions would not be cost-effective to do ‘correctly’. Many business solutions also don’t have the lead time to do ‘correctly’. So the first truth is that these tactical or temporary solutions will always be required.

2) It is likely permanent

So if the tactical solution is required, what can we do about it? Well, first don’t believe the promise that it is a temporary solution.

Typically temporary solutions are created for items of smaller business value. If there were more value, there probably would be a reason to develop a better solution. So why would the business invest in a larger ‘correct’ solution when a smaller, tactical solution delivers the expected value? The answer if of course, that they won’t. There is a good chance that if the tactical solution is ever replaced it will be replaced with just another tactical solution.

So What Are We To Do?

So these temporary solutions will always be required and it is unlikely that a temporary solution will get redone ‘correctly’. So what are Software Development professionals to do?

The best we can do as Software Development professionals is to go in with our eyes wide open. Understand that the solution stands a pretty good chance of being permanent. Then try to design the solution as good as possible within the constraints. Don’t totally resign yourself to bad practices. Insist on small pieces of value that return great benefit if the solution needs to be maintained for years. Make the solution as data driven, parameter-based, highly cohesive and loosely coupled as you can. Don’t build in extra functionality but build the functionality so it is easy to adapt to future changes.

Also understand that not every business problem needs or deserves a perfect solution. Some solutions that are not robust may be the ideal solution for the problem at hand. We don’t always need to create a perfect solution. The solution should be just enough to deliver the required business value. I believe that as Software Development professionals we frequently forget that.

If we do these things we will find our lives easier as we try to maintain these solutions. We will also build confidence with the business as we are able to adapt to some future changes with these temporary solutions. It also is a good reminder that not all business problems deserve a strategic solution. The solution should just fit the business problem.

Three rules to make Stretch goals work

Many times late in projects we frequently see the use of stretch goals to instill a sense of urgency and motivate the team. But do they truly work? Many times stretch goals are applied in a manner that can actually cause them to be de-motivating rather than motivating.

In my experience, there are three rules that need to be followed to make stretch goals work:

1) Collaborative Goals – The goals need to be collaborative. There is nothing more de-motivating than someone else making a stretch goal for you with out your input and consent. These goals will end up being ignored as the team members are not engaged on the stretch goals.

2) Realistic Goals – The goals also need to be realistic. If the goals are not merely stretch goals but also impossible goals, the team members will lose their motivation to try to reach them. Impossible goals will have the opposite effect. Instead of people putting more effort in, they will put even less effort in as they are doomed to failure.

3) Empathetic Goals– This is perhaps the most important rule. Even if the stretch goal has been set collaboratively and is realistic, there is still one more factor. Team members need to understand why they should care about the goal. I read a fascinating book called ‘Leading Geeks’ that proposed that geeks and other professionals can’t be just told what to do. They need to be reasoned with and convinced that the goal is appropriate and worthy of their care.


Can Stretch goals work? They certainly can if they follow these three rules.

But I find what usually happens is that there is an issue following one or more of these three rules. Either there is a hesitancy to be collaborative or the goal may not be realistic. Even more, there may be a challenge convincing the team as to what the reason is for the goal. In those cases, the stretch goals will probably be more de-motivating that motivating.

I understand there are reasons for stretch goals being demanded of projects teams and sometimes they can’t be modified or rejected.

But you also should know they probably aren’t going to work.

My #NoEstimates disappointment

I must admit I usually come right in the middle between No Estimates proponents and the traditional estimators. I usually like the process of estimating on my projects, but I certainly see the downsides of such estimates.

I also do think estimates and no estimates and Lean Start up are not mutually exclusive. I can still do estimating on a project that I am executing in a Lean Startup method. Sometimes I think we search too much for discrete and absolute answers.

Anyway, that wasn’t what disappointed my about No Estimates this weekend. Rather it was a link to this announcement.

My Opinion

If you haven’t clicked on the link, it is an announcement to a No Estimates workshop in October 2014. The link also asks for questions to be submitted to be answered in the session.

So why did this disappoint me?

I’m always disappointed when the pursuit of new ideas, methods, and practices become an economy. I’ve asked some questions of the presenters before and it was mentioned that they would add it to their list of questions and perhaps they would do a future blog post on the subject. Now it appears to get those answers I may need to attend a workshop in Europe. I’m disappointed because I was hoping to hear the answers to those questions other the next few months. Now perhaps I’m wrong and hopefully this workshop will not hinder the flow of ideas over the next few months. But there still does seem to be many questions out there that are unanswered.

For example, “What you you recommend I do first to try No Estimates on a project?”

I Wonder

I also wonder if the No Estimates workshop will be done in tune with No Estimates principles? For example:

1) Will a full price for the workshop be estimated and required up front? Can I attend for a day and leave for a day if the value I expect isn’t being realized? Can I pay day by day?

2) Will the workshop have a set agenda or can the attendees define the agenda in the first hour collaboratively?

3) Couldn’t we try to answer a few of the questions listed first and validate people would get value out of the session before committing a week of time, considerable training budget, and fossil fuel to jet to Europe?

It almost feels like a week-long workshop is against the principles of No Estimates.


I’m disappointed as I fear there may also be No Estimates certifications down the road ala PMI and Six Sigma.

But I fear that No Estimates will join the establishment of training courses and specialized consultants. No Estimates to me was always about challenging the establishment and not joining the establishment.

As Obi-Wan said in Revenge of the Sith – “You were the chosen one! It was said that you would destroy the Sith, not join them. You were to bring balance to the force, not leave it in darkness.”

Hopefully I’m mistaken.




My #SoftwareDevelopment plumbing experience

Last weekend I was looking forward to leaving behind my Agile and Software Development challenges and do some work with my hands. My wife wanted a new bathroom vanity. We were buoyed by the false hope gathered by installing a new toilet successfully the prior weekend. I mean how hard could this be? I’m sure everything is pretty standard in plumbing right?

Off we go

Well we started at Home Depot like all good stories do. Tracy picked the appropriate vanity and sink based solely on the room available in the bathroom. She even picked a sink with some additional nice-to-have features like an aesthetically pleasing control to stop up the sink when required. All was good and positive vibes were all around. We felt proud that we even thought of extra items like silicone and flex pipes that would be required to install the sink.

The project

 Phase I – Teardown

So the first phase was obviously to tear out the existing vanity. No problem. Just reach under the sink and empty it of all the items stored below. Ok, now just to turn off the water. What the? Who would install a sink without shut off valves? Really? Off to Home Depot for trip #2 to get shut off valves and install them on both pipes. Already blown my estimate for the tear down work. I thought I’d be able to remove the entire old vanity in an hour. Turns out it took 3 hours. But at least it is done.

Phase 2 – The new vanity

With the tear down a bad memory in the rear view mirror we moved on to installing the new vanity. Over dinner the prior night I mentioned my concerns about whether the drain would line up as the new vanity and sink are wider. Thinking ahead I measure both and determine there are no issues. Awesome.

We lug the vanity upstairs. Lots of drawers and solid construction make it quite heavy. We line it up and two things becomes immediately apparent. The drain coming out of the wall is too low and we will need to cut part of a shelf out to allow us to install the vanity. No problem. A larger problem is that the drain coming out of the wall is 5 inches shorter than required.

Really? Seriously?

Can we all get together and standardize on some key interfaces like the height of the drain from the wall and the distance out from the wall?

The people at Home Depot and I are on a first name basis now. I end up buying some PVC pipe, connectors, a new trap, and a couple of spare parts just because I’m getting very nervous.

Phase 3 – Integration

Alright, I’ve called in some back-up in the form in the form of my brother-in-law. We manage to assemble the new trap and are ready to hook up the sink.

But first we need to assemble the contraption that puts a stopper in the sink by pulling a lever. One problem, one of the rods is way to short? How could this be? Then the answer comes from below, the taps did not come with the sink. Suddenly we are dealing with the reality of trying to integrate three independent pieces – the vanity, the sink, and the taps.

OK, we put aside the stopper contraption for now. lets just get the drain hooked up.

In looking at the sink pipe, there are two holes in the sides of the pipe? Odin’s beard, why would somebody places holes in the sides of the pipe? There is a stopper below the holes that I suppose will prevent leaking if we tighten it enough, but I’m still dumb-founded as to what purpose the holes would serve.

Turns out the holes were our downfall. We had leaking we couldn’t stop, so we over tightened the stopper and we stripped the drain connection. Sigh


We left defeated to retrieve a beer. We will attack it again next weekend.

Then over drinks later I thought of a question my wife and kids always ask me. “Dad, what do you do at work?”

I looked at them and stated:

“Remember all the problems we encountered and needing to find unique solutions ? Remember the questions why someone would design things like this? Remember the frustrations and rework we needed to do?

That is Software Development and what I do every day.

My wife actually got me a second beer.

Three confounding characters in the Software Development #zoo #agile

Someone asked me how I come up with topics for my blog posts. I responded by saying that most of them just kinda appear by something I read or see. Today’s post was one that just appeared out of the blue in a new way. I drove past the zoo.

As I drove past the view, I was thinking about the different animals and the personalities they have. Then I thought about the three characters I find on Software Development that sometimes vex me. Now these are not specific to Software Development projects. You may even see these characters out in the wild on Twitter.

The Three confounding characters

1) The Parrot

Natural Habitat: The Parrot can be frequently seen on most projects. The Parrot is most at home in meetings and group discussions.

Behavior: The Parrot can typically be seen in meetings echoing what others have mentioned to be issues for the project or mentioning tasks that still need to be done. The issue with the Parrots are that they are usually unable to provide suggestions or recommendations on how these stated issues can be resolved or addressed causing frustration with other team members. They also hesitate to take on tasks that still need to be done. Ironically they are viewed positively by clients as they continue to mention issues that affect the clients. But ultimately they contribute little to the resolution of the issues or tasks.

2) The Owl

Natural Habitat: The Owl can be seen on most projects. The Owl typically dislikes meetings and instead prefers to make nests and have one on one conversations.

Behavior: The Owl typically displays territorial behavior. The Owls like to have tasks and roles clearly defined and are on the watch for any tasks or work that cross these boundaries. If problems arise on the project, the Owl is typically the first to place blame and ask ‘Who?’. Who is responsible?, Who didn’t do this correctly?, Who designed this?

3) The Zookeeper

Natural Habitat: The Zookeeper can either be found on projects or in the wild on Twitter. 

Behavior: Sometimes the Zookeeper can exist on projects, but usually Zookeepers flourish on Twitter. Zookeeper’s behavior typically revolve around placing people and ideas in the cages they alone define. New ideas and innovations that do not fit existing cages cause Zookeepers great angst. Zookeepers typically spend a lot of effort either ensuring that ideas and tasks fit into their preferred structure or criticizing and discrediting ideas and innovations so that they don’t need to be accounted for. 


Thankfully there is a pattern that can help with these three confounding characters. Agile. By having a true cross-functional team, these characters are integrated more into the team and many of the behaviours are muted. All team members are expected to contribute to solutions, have collective ownership, and embrace ideas and innovations from everyone.