If you haven't seen the videos for the BumpTop Prototype, you should check these out. I'm dying for this to be released.
Beyond the desktop, it would be really cool to have this functionality available for applications.
Archive for June, 2006
23
Jun
BumpTop Desktop
23
Jun
TIB #9: Design Matters
Design matters.
Design tends to be overlooked, but it’s extremely important. It matters in products, it matters in software, it matters everywhere.
If you have publicly-facing web services, it's likely that you don't want to expose the inner workings of your application to the consumers of the application. In the application that I'm currently working on, there are times we want return a generic "An unexpected exception has occurred." message and times that we want to return the actual exception to the client (for validation / policy-related exceptions). In both of these scenarios, we do not want to return the stack trace that indicates where the exception occurred.
There are many ways to implement this functionality, but the good news is that this is the provided behavior (by default) of a .Net web services project. The bad news is that it's probably not immediately obvious that this behavior is occurring because it is only the default behavior if the request is coming from another machine. If you consume the service from a client on the same machine (more than likely, this is the case when you are testing) then the stacktrace will be visible.
The secret to controlling this behavior is the customErrors tag (and the mode attribute) in your web.config file. A customErrors tag with mode="On" will remove the stacktrace from the soap fault (even on the local machine), a tag with mode="Off" will add the stacktrace to the soap fault (even for remote clients), and a value of mode="RemoteOnly" will add the stacktrace for local requests and remove it for remote clients (this is the default).
It was a big surprise to me that this tag controlled the stacktrace of web services. This is a common configuration tag, but I had never seen it used with web services.
The code to remove the stack trace (for both local and remote clients) is:
1: <configuration>
2: <system.web>
3: <customErrors mode="On" />
4: </system.web>
5: </configuration>
For more information on working with soap faults, take a look at the Using Soap Faults article on MSDN.
A while back, I wrote about defining my TIBs. I’m still not done, but I’m going to randomly post a few from time-to-time. I don’t have them listed in any particular order, but here is TIB #1:
Custom software is too expensive.
There are many factors that eventually come together and make the world of custom software development more expensive than it should be. I believe this is because the majority of our focus in the field is primarily focused on technology solutions instead of business solutions. Sound software craftsmanship and business accumen can go hand-in-hand to create functional, beautiful, simple, and valuable software if we step back and question our assumptions on how software should be developed.
On the project that I'm working on, we are currently tracking our sprints with index cards (on a wall gantt) and by daily/sprint/release burndowns in a spreadsheet. The wall gantt is the tracking that is used for our day-to-day tasks and the spreadsheet is used more as a communication tool for our external stakeholders.
Our team has recently run across some issues with a few third-party software packages that have impacted our velocity and required some additional tasks. As part of the on-site team, my visibility has mostly been with the wall gantt. I've noticed that our velocity has taken a hit, but I wasn't sure how our velocity had trended over the release as a whole.
I recently ran across sparklines and was interested in using them to take a look at our velocity. I was extremely impressed by how much information could be viewed in a short space.
It's fairly obvious where the trashing started (around sprint 10). The sparkline shows a daily story-point burndown inside of each sprint. The high and low points of work remaining for each sprint are shown through the different colors. For the spreadsheet, I used the free Bissantz tool (thanks guys).
I'm looking forward to picking up Beautiful Evidence by Edward Tufte and reading about more visualization patterns. Reading his work is always extremely insightful.
Why is it that a general best-practice is to have strong passwords when most applications don't support them? I tend to use (very) strong passwords, but it seems like I'm discouraged more often than I can utilize them.
Is it really too much to ask?
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.
