I held a presentation at AS2010 about handling defects. The slides are up, unfortunately there is not text in the slides and there’s no audio track… but for those who wish to see my slides you can find the at:
I’ve been thinking a bit about all these factory references that occur when discussing software development. So here is an inventory management view, I guess.
Inventory, viewed from a lean perspective is waste. If you can keep your process running with minimal inventory, then you can decrease costs for changing the process.
Software is immaterial, so there is no “inventory” per se. But, there are equivalent cost scenarios.
Here are a few examples of inventories that occur during software development:
I’ll describe the cost scenarios for these examples, there is probably more.
As soon as you write your documentation, it starts aging. Documentation, be it help documents or documents describing the system, are like groceries. They go old, and they do so in different rates. Some documentation is more resistant to change while other gets outdate faster than you can write it. This implies a maintenance cost for documentation, either keep it up to date or throw it out. The cost of someone using old documentation could be very expensive.
A favorite of mine. Every version you have in production has its own personality, it’s own quirks, features, bugs and what not. This implies greatly increased support costs.
Source-code is also a sort of inventory. The more code there is the more there is to maintain. Sure you might not change the code all that often, but unless your code is separate products, it interacts. Larger code-bases require more testing (be it automated or manual testing). Good design helps reduce the size of the code base, and from a cost perspective keeping the codebase low is very important.
Issue tracking systems is just an inventory of reported issues. As it grows the cost for maintaining the issues grows. Every release has the potential to solve any issue, which could at worst imply workload on developers to keep, not only the source-code and documentation up to date, but also the issue tracking system. Secondly, if it takes too long between something being entered into the tracking system and it being fixed. Then the people, stakeholders, for that issue have forgotten about it or worked around it in some way. Also most of the time, the act of managing and tracking the issue costs far more than just fixing it.
So what to strive for, only keep documentation for which you commit to writing and maintaining. Have one version of the system in production, and get mechanisms into place to quickly update all clients so you can keep it so. Keep your code-base small, strive to solve problems using better design and less code. Think more, code less. Last but not least, fix problems as they occur, strive for zero-defects. If your using Scrum you can handle issues in a sprint, but avoid long-running tracking.
I was working on performance tuning for the mobile client of RemoteX Applications when I found a tool called EQATEC Analytics. Six month later I added it to our clients for the first time.
EQATEC Analytics is quite interesting, for RemoteX it solves an interesting issue. Error reports are hard to collect from Compact Framework devices, especially since all error messages state that “we’re missing the translation pack to translate these errors, thus you get this crappy errors message instead”.
EQATEC Analytics captures all unhandled exceptions and report them back to a server application for analysis. This means that all crashes are reported so they can be analyzed by us, without involving the user in the information collection process. (no personal information is sent to the server)
The benefits of this enormous. We can see the quality trends of our applications (at least when it comes to crashes), and fix the errors that occur the most.
Traditionally the errors are fixed based on the information received by customers, manual error reports and what not. Relying on this type of information means that you fix the errors that most people report, or the errors you can reproduce. With EQATEC Analytics you, you can get an exact stack trace indicating the problem area, and depending on how you configure it to work you can also request information regarding what was happening during the crash.,
It also provides an excellent way to see if our efforts of improving the quality of the product is helping or not.
Now it also has features to collect information about what kind of system our applications are run on, and also collect statistics of which features are used in the applications.
We’ve used EQATEC Analytics in production since January 2010 and so far we are very happy with the results.
An interesting note here is that the next version of Shuffle will use a similar tool for Android, called Flurry.
Sometimes I’m amazed. I came to work this morning, and someone came at me in slight panic. A system that is central for our customer operations is having an outage what do we do.
Apparently what they had tried to isolate the problem was checking again and again if the system was working. Basically just trying to refresh in the browser.
What they hadn’t done was to try to troubleshoot it.
How do you troubleshoot?
You isolate all other components that can fail and follow the error as close to its source as possible.
I came in isolated one piece of commodity technology between them and the service they were trying to use. And voila it worked.
The piece taken out, the handset. Once plugged back in the handset worked again.
One of the most important aspects of solving any problem is to isolate it. If you don’t; every attempt at solving the problem is just guessing or brute force hammering on the problem (brute force attempts have a high risk of breaking stuff and a less of a chance to solving any problem. Sometimes however, it just feels good)
Last week we had a code sparring session in Stockholm under the flag of Alt.Net Sweden.
Peter Hultgren, also a member of Alt.Net Sweden came up with the idea. During the Coding Kata held a few weeks ago at Avega we identified a few problems with the setup.
one of the problems identified during the coding kata was that a lot of people were idle, or non-productive. There was a lot of discussion etc. all due to the fact that there were 8 people and 1 keyboard.
With the code sparring setup there is a set up of 2 people per keyboard (maximum of 3). Meaning several different solutions. We also published which kata we were going to do in the invitation so no time would be wasted on deciding what to do.
RemoteX hosted the session at the new office, offering Beer and Pizza to the 11 participants. We did the Yahtzee kata, with 20 minute rotations. With 5 people stationary at their own computers, so everyone providing a computer felt comfortable with doing so.
This meant that we could have a full rotation in the given time frame.
As far as I could tell everyone had a good time. Of the 5 different solutions here were a few quirks:
It was quite interesting to see the different setups, and solutions.
Some reflections:
The Yahtzee kata was a bit too simple to produce any interesting variations. Perhaps if it had been set up with Object Calisthenics it could have resulted in more variation.
These last couple of days we have been having a internal TDD course at RemoteX. We had the help of Andreas Brink, whom guided us in testing and over all code quality.
One of the things I noticed during the course is how heavily influenced I was by old habits. We’ve been doing testing for a while, and fallen into the habit of isolating everything using mocks.
One of the things I learned this last week is that mocking is a great tool, but shouldn’t be used as intensely as we have. When pointed out to us we noticed that the way we used mocking actually introduced more code in the tests than we had to.
The order of setting up and doing assertion’s was often distorted since the mocks didn’t have state. Expect calls for example are typically set up in the beginning of the tests, but checked after. Meaning that the verify code is at a different location than the code saying what is verified. End result, the tests aren’t as clear as they could be.
But the influence of habit doesn’t stop there. Details such as how much you use the mouse or keyboard, or utilize the tools available are all depending on your habit for writing code.
For example I have a colleague who knows the keyboard shortcuts, but has the habit of using the mouse. This habit is so heavily indoctrinate that when he is on a laptop, he reaches for the touchpad instead of using the shortcut. The touchpad on my laptop has low sensitivity so the time to write code is heavily hit every time you reach for it.
Hard part is to notice your own habits, some are good, some are bad. Both are good to be aware of.
“I can look at code and understand it but i cant write code”
There seems to be a common misunderstanding that if you can read code and “understand what it does” you understand the code. I’m sorry, If you cant write the code yourself, you do not understand the code.
Being able to read code doesn’t mean you understand it. Anything can hide in those pretty method names.
.Net rocks had a panel discussion a while back, regarding the increasing complexity of software development. A panel discussion they have been refereeing back to a few times in the shows since. In general venting the possibility that all the options available is just adding complexity and might not result in any business value gain.
To contrast this I’m currently listening to the Stanford Entrepreneurial Thought Leader Lecture Series podcast, where they recently had Quincy Jones III and Chamillionaire talk about Successful Independent Promotion: From Artist to Entrepreneur. Where they are excited about how web-development is becoming simpler, and more accessible to “urban” artists.
The contrast is quite interesting between the two pod casts, one talks of adaption and innovation. The other focuses more on consequences of the work of others.
I just realised that a while back was 24 issues of Dot Net Rocks ago, and congratulations to the 500th show of Dot Net Rocks.
My time spent in meetings has been increasing the last couple of weeks. I’m no fan of meetings. One of the reasons I don’t like meetings is that most of the time they are not as productive as they could be.
So last week I had an idea, or rather two, I thought I’d share.
Naturally there are meeting techniques to increase the formality of the meeting, but these shouldn’t be necessary unless you need a formal protocol from the meeting.
I went through a business contract, analysing it for weaknesses. I found a not likely case, but still pointed it out.
“You should be a lawyer”, the lawyer says
“I write laws”, I reply.
Now why am I writing this?
Well, there are similarities to developing Laws and developing business systems. Laws are rules in which we humans can work within to achieve value. The value Laws strive for is the value of functional society, a functioning system.
Now developing business software can be viewed in the same way. When developing the software we state the laws in which the users can generate data. The UI is a constraint or law, the business rules are different kinds of laws, and so on. The value we strive for is correct business data, another kind of functioning system.
How it is to live under these governing systems i based on the values they are built upon. A Mac user have different values regarding usability, design, and in some cases “quality” – compared to a Windows user.
Developing software is a team effort. The development team are the legislators of the product they are developing, so which values are governing your software?
