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

Conclusion

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.

Is #agile #sub-optimal?

I had a comment that was posted in relation to my Solution Driven Development post that took me on a journey of reading on Sunday. It was a comment submitted by Gebhard Greiter.

To be honest, the comment and its references proposed a more rigourous and prescriptive process that what I prefer to see in my Agile projects. (I’m just not sure I’d recommend that the designer is a separate person than the coder) But I appreciated it’s sentiment. Gebhard, like myself, is struggling to find that correct balance between traditional and Agile processes. I commend him for the principle and strength of convictions, even though my preferences in project execution are slightly different than his.

His proposed balance between the two sides of the methodology can be found here:

Comparing two process models for Software Development

There were also some interesting links or sources of information in the comment. The first one was the Principles of Agility 2011. This link then referenced a Gartner report and quote on the potential downside of Agile. I found the entire article that generated the quote and you can read it at the following link:

Agile Development costs more in the long-term

Is Agile Sub-Optimal?

After I read he article, I had two thoughts. One, that the article drew some broad generalizations and perhaps drew some conclusions I would not have drawn. Two, is the author may be onto a small nugget that has been bugging me for a while.

I’ve always been bothered by the lack of ‘project memory’ if I following Agile by the book. If I use User Stories on stickies, Manage via a Kan Ban board, and my retrospectives, application and automated test cases are primarily my documentation at the end, can I answer the following questions?

  1. How can I search prior projects for leverage opportunities? Must I read through the code and tests and somehow determine leverage opportunities?
  2. How can I review prior projects history for a history of how estimating worked so my estimates can be better this time?
  3. Since we acknowledge that I there is never enough time to create all the automated test cases, how do I know if a new requested change is implementing behaviour that is beyond the intent of the application and will cause downstream effects that I can’t anticipate because we don’t have an automated test to ensure its correctness currently.
  4. How can I ensure my solutions are consistent across projects if they don’t have high level knowledge of each other?
  5. How can I easily have new team members support the system? Do they read the code and the tests?
  6. etc….

Active Architecture

I had written a blog post that described my approach to creating Active Architecture Stories as a means to create just enough design documentation so be able to answer half of the questions above. I think the other half can be solved by using one of the leading Agile Project Management tools out there like TargetProcess, Rally, or VersionOne. Any of these tools will allow you to start to build up that ‘project memory’ that can then be leveraged by other projects.

Summary

But the question remains, “Are we sacrificing long-term Enterprise objectives by developing project in an Agile way?” I don’t believe that anyone that argue that Agile is not the best way to execute a project. But I do think that sometimes Agile’s sole focus on value for the project and client may cause us to lose focus on the value the IT Department and the Enterprise requires across all the projects. By its very nature, Agile Software Development projects are silo-ed projects with primarily full-time members and with little governance roles breaking down the barriers between projects.

Sometimes we may need to create documentation that the client does not see value in currently. As professionals we know that there are some documents that will be required in the years following go-live that will pay for themselves 10 fold.

Am I proposing functional specifications? Absolutely not. But I think there is a place for more documentation and some up front design and architecture than is usually suggested. The real question is what documents are required that will ensure I can take advantage of all my re-use opportunities and also be able to efficiently manage the application for the next 15 years.

Perhaps we should also ask those questions when we are determining if we need to create documentation.

#Innovation Debt and the Four Fences of Software Development

I was looking for a new picture for the Blog and I thought about an interesting Blog post. As you can see now, I chose the image of a gate after much searching on various image search engines. (let me tell you there are some very interesting people out there with cameras.) 🙂

Gates and Fences

I chose a gate as I think it is a very interesting analogy that can be used in the Software Development industry. In the Agile community we are so focused on tearing down fences that we have to be careful we don’t use the remnants of the Waterfall Fence to build the Agile Methodology fence. I loved the analogy of a gate in conjunction with the fences. We need to ensure that every fence we build also has at least one gate. The fences exist for the purpose of providing structure and restrictions for predictability, but there always needs to at least one way to break free when the situation calls for it.  (hopefully multiple gates)

I thought of 4 separate fences that are quite common in the Software Development industry. They are:

1. Process Fence : Gate leads to greater value

I’ve alluded to this fence already. As I have mentioned, we in the Agile space need to be extremely careful that we don’t construct an Agile fence out of the broken boards of the Waterfall fence. If we start being equally as stringent and demanding, we are equally doomed to failure. Don’t get me wrong, I think the Agile practices are a great fit for the vast majority of projects and an improved over the Waterfall methodology. But we need to be careful that we don’t start to be overly prescriptive and cookie-cutter. It would be incorrect to say all Software Development projects require pair-programming, two-week iterations, and daily stand ups. Just like it was incorrect to say all Software Development Projects required Functional Specifications, Work Breakdown Structures, and Use Cases. Do these Agile practices fit better than Waterfall practices? Usually. But the team still needs to determine what practices best apply and to what extent.

Sometimes you have to open the gate and incorporate all the different practices that deliver the most value to your client. It is likely that these practices will be from many different methodologies. Can an Agile project benefit from a Work Breakdown Structure? It is possible.

2. Technology/Vendor Fence : Gate leads to better solutions

A second fence we can find ourselves in is this Technology or Vendor fence. This is the fence that we typically build around the technology we use and the vendor for that technology. We typically built these fences for very good reasons. Simply put we are more familiar with the technology we use the most and we there just isn’t enough time to learn all of the technologies that are out there. There are just simply too many. So what can we do?

I think similar to the Agile principle about trying one new thing every iteration, Software Development technical professionals should try one new technology every project. (preferably from different vendors) If the project doesn’t allow for this, then we should as Software Development professionals commit to reading one new book and playing with one new technology in our own time for every new project.

If we don’t do this continuous learning and strive to open the gate in the technology fence, how do we know we are providing the client the best solution? Of course we can’t know all technologies, but isn’t it our professional responsibility to know more than one group of them?

3. People/Employer : Gate leads to enhanced knowledge and competencies

The third fence is the people or employer fence. This fence is very similar to the last fence except that it deals with people instead of technology. It is very natural to again build a natural affinity to the people we primarily work with. But it is also important to realize that one company can’t be perfect in everything. (just like one person can’t be the best at everything) We all have our strengths and weaknesses both individually and corporate-wide.

Some of the most valuable lessons learned I have had over the years has been when I have worked with people from other companies and they have shared with me their practices and methods. Now those of us who have worked for a company for a longer duration obviously believe our company has more strengths than weaknesses. (I know this is something I believe 100% about Protegra.)

That said, I look forward to being able to work with new Protegrans and with new partners and clients because I know I am going to learn new things and be the better for it. Opening the gate in the People and Employee fence is one of the most rewarding.

4. Experience/Safety : Gate leads to innovation

The fourth fence is one we build ourselves and it is something I’ve noticed more in myself as I’ve gained experience. I think sometimes when we have gathered more experience, it is easier to just do what we have done before. Developing using a known process, technology or team is the safe route and something we feel more comfortable with. The decision between introducing new items and doing what has been done before is a fine line as we can’t take on too many new things and risk the project, but if we don’t take on any new items we are building what I like to term Innovation Debt.

Like Technical Debt, it is sitting there and charging interest. Innovation Debt will also needs to be paid sooner or later and it is better to pay it off bit by bit on projects rather that having a large payment at the end. The real problem is that too much Innovation Debt can result in a compromised company that is passed by their competitors. Too much innovation on projects can result in compromised projects. It is a very fine line to walk.

But not opening the Experience gate is actually more damaging that opening it. It is just a little unnerving at first and requires an atmosphere at work that encourages innovation and rewards fast failure.

Summary

Those are the four fences and gates that I try to keep in mind as I go about my projects. Does anyone know of any more?

Seek to Understand, Strive to Educate, Commit to objectivity

This post has been percolating for some time in the political and journalistic realms. Very recently it has also found a home in Software Development. But let us start at the beginning.

I love the opinion and editorial section of any paper. I love reading people’s opinions about items in the news. I also find the editorial section extremely enlightening in regards to current events. That is until the last few years. It seems over the last few years, it has been very hard to find a balanced opinion article in the paper. The articles are bordering almost on propaganda. And it isn’t just either the left-wing or right-wing articles. The unbalanced articles are across the board. It seems all the articles are no longer trying to educate or inform, merely convince.

As a Canadian, I am interested in politics in a moderate way. I don’t align myself to any one party and feel that there are parts of every party that I agree with. I am constantly disappointed with political articles, editorials, and opinions that don’t provide a balanced viewpoint. Usually the point of the article is to convince the reader through fear, uncertainty, doubt, and junk science. By reading the articles around the recent Canadian election I would have thought that the leaders of the major political parties were inherently evil, naive, or simple. Of course, none of this is true.

“Education is providing balanced information on the entire issue, propaganda is providing information on only one side of an issue.”

I believe that if a person is 100% aligned with a concept, group, or ideology, he or she has probably stopped being objective.

So what does this has to do with Software Development?

First off, I’d like to provide full disclosure. I am neither a devoted fan to either Microsoft or Apple. My technical assets are:

  • Imac and Mac mini at home
  • Dell laptop at work
  • Blackberry Phone
  • Ipod music device (Classic black if you must know)
  • Nintendo Wii Game System

It seems that Software Development has recently fallen victim to the same hyperbole that has befallen politics and journalism. Many tweets I hear and articles I read seems to imply too quickly and frequently that the specific technology is a ‘game-changer’. Those types of technology happen very infrequently. I shudder every time there is a Microsoft, Apple, or other large technology announcement is made. I know there is going to be a plethora of tweets stating how Windows 8, OSX Lion, or Google+ is going to rule the world and be a game-changer. Even methodology discussions are victim to this behaviour with the demonizing of Waterfall and the praising of all things Agile. (without acknowledgement that there are situations that each excel at)

But more it seems that people are becoming 100% aligned with products and vendors. Can they really be considered objective? Shouldn’t there be some products from preferred vendors that they don’t like? Am I the only one that thinks Google+ is mainly Facebook+Skype+new cool user interface for groups? 🙂

Truth is that I would love to read more balanced articles that seek to understand these technologies, strive to educate me on these technology options (good and bad), and then commit to provide a balanced objective critique.

I know I myself have provided these somewhat one side articles in the past, but  am going to try to focus on providing more balanced articles going forward. You may not agree with my conclusions, but at least I will try to paint the picture in a balanced way that lets you decide for yourselves. Sometimes I may like Microsoft, sometime Open source, sometime Apple, sometimes COBOL….

Programmer Anarchy

I came across this great presentation on InfoQ about Programmer Anarchy the other day. I had not been exposed to many of these principles and they can be somewhat controversial.

While some of the principles may not fit for everyone, I think there is something for everyone in these principles.

I hope you enjoy it as much as I did.

http://www.infoq.com/presentations/Leaner-Programmer-Anarchy

Number One rule of Software Development – Its the People Dammit!

As promised in my last post, this post will be all about what I believe to be the number one rule of Software Development. Now there are many factors that go into great Software Development projects and products but ultimately I think the best results have come from the same factor. The people. But specifically it is a certain type of person and focus in those people.

Protegra is very focused on finding the right people to fit into our team because we understand that at its heart Software Development is a social activity. Like any other social activity or team sport, I believe the most important attribute is the drive to strive for continuous improvement. If you strive to be better than you were yesterday, you won’t have to worry about being better than other people. That will eventually take care of itself.

A phrase a fellow Protegran used was ‘Student of the Game’. If you have Students of the Game, I have no doubt the your project and your company will succeed. Students of the Game bring the following skills to bear on a project:

  1. No personal Ego
  2. Relentless pursuit of new ideas and innovation
  3. Fearless approach to trying new things
  4. Constant focus on getting better
  5. Unquenchable thirst for knowledge
  6. Deep involvement in the community and mentoring
  7. Contagious & Passionate approach to all aspects of work
  8. They are Brave
  9. Client Focus

This Student of the Game approach is core to the Agile approach. And also at its core they must trust that co-workers at all levels have their backs as they are brave. This is crucial. If this does not happen the risk taking stops and the Students of the Game leave for another company or just execute in a safe manner that never challenges the status quo.

But you may ask, ‘Terry, if I have these students of the game, won’t I be adding risk, constant change, and constantly gold-plating solutions?’ These Students of the Game must be students of the technology, process, and business acumen. We are not just talking about the technical Students of the Game. These Students of the Game need to be balanced across the facets of the project.

Just like anything else, these passions also need to be moderated. And the most important moderation is that all these improvements need to be tempered and grounded in value for the client. As we pursue these ideas, if our focus is solely on value for the client we won’t be led astray. We should never be doing anything just for the sake of trying something new. It has to have expected benefits for the client.

So how do you find these Students of the Game? They will be wearing the white hats…. 🙂