The Sherpa Project

I ran across this post earlier today about integrating Nabaztag with CC.Net.

I have to get one or two of these things for our current project

YAGNI as a development concept is a very powerful idea. The idea of making a decision at the last responsible moment saves money, effort, rework, and will often save sanity. The idea is very simple and bascially revolves around removing speculation. When we constantly think in terms of YAGNI, we are often mitigating one of the largest risks to software projects.

In my experience, extensibility is usually the largest risks to a software project because it often results in the largest degree of over-engineering. This usually isn't a popular idea, but I think it's true. There are times when it's warranted and valuable, but the problem is that we tend to always think that it's valuable. We always say things like: "what if", "someday", "it's possible that", "I can imagine a scenario", and so on. These are usually things that should be considered, but not always things that should be developed. In theory, we need to pose these questions to our stakeholders and our stakeholders should be making these decisions (not the development team).

The problem with the theory (allowing the business team to make the decisions) is that they are often caught up in the same vicious cycle of over-engineering our specifications. When I'm handed a large requirements specification document, I know that 25% of it is outdated, 40% of it will never be implemented, and that the real value likely comes from 20% of the requirements. The state of the specification is a result of over-engineering by the stakeholders (and it compounds the issue of over-engineering by the development team).

I don't have a silver bullet to fix the issue, but I believe that we can at least identify the problem and get in the correct mindset of fixing the problem by thinking about how to eliminate waste. Simply considering known value vs. speculative value can go a long way. We should always be thinking about doing less. Less is a powerful idea because of the compounding growth of each additional thing that we choose to do. For every "I can imagine" scenario, we have business costs, development costs, testing costs, and maintenance costs. We also have other costs that we usually don't think about including opportunity costs.

To push the idea further, we should consider the idea of "less" across the spectrum of our activities. One big opportunity comes with documentation. I think that The Elements of Style should be required reading for everyone that contributes to documentation on a project. Our documentation should be concise and avoid all the additional "fluff" that makes up the majority of the large documents that I see on typical projects. Documents should be focused to the point that every word in the document has meaning just as every requirement should be valuable and every bit of software should be testable.

Unfortunately, the idea of more is the norm. The positive side is that we are the problem and we can all take steps to eliminate waste in our day-to-day activities. If we don't do anything else, we should at least consider how the idea of "less" can apply to our projects and our organizations. It's not an overnight change, but it is a valuable exercise in thinking about what really matters.

I ran across this article from Fortune discussing the history of the cubicle. In my view, cubicles have been the primary catalyst of bad organizational communication. I've always hated cubicles and the silence that usually accompanies a cubicle farm in the majority of the offices that I visit. Regardless, it was interesting to read about the progression of the cube and the fact that the original creator (Robert Propst) was likely not happy with what the concept has morphed into.

I'm glad that there are quite a few companies and individuals looking into ways that we can reclaim the original idea of maximizing our workspaces. I'm not sure what the right answer is, but I know that it's not based on restricting communication. At least for development purposes, I think we all need to get outside of the cube. There are some interesting thoughts posted on the C2 wiki, but my recommendation would be to burn the damn things.

Disassembling cubes is nice, but the problem is that they stick around to haunt new employees or they go and spread their evil to other workplaces. If you burn the cubicles then you have a great excuse to have a party with your employees and you can all celebrate the removal of communication barriers. I haven't had the pleasure of attending a real cube bonfire, but I'm hoping that one day I'll be able to participate.

In the meantime, I suggest getting everyone in one room. It's hard enough to deal with our day-to-day issues that come up in the business world and sitting together allows for the free flow of communication and ideas throughout the team. There are justifications for needing privacy, but the times for privacy are fewer than the time that's typically needed together. Everyone needs a space where they can get away, but this should ideally be the exception and not the norm.
BTW, if anyone gets some buy-in to have a bonfire please invite me.