Agile Otter Blog

using(Playback) {    sut.PerformAction(parameter); } This is the last part of a common style of mock test. We see the system-under-test (sut) being asked to perform some action, and some parameter is passed to it.  We know it's a mock test because of the Playback bit.  What is being tested here? Well something about PerformAction is being tested. Not much there. No clear assert written at the bottom of the test to capture our attention. Let me narrate as I work through the actual code before me, and maybe the readers can respond to tell me whether this really is mocking done badly, or I'm "just not used to good mocking." I struggle not to look at the test name, so the code can speak to me more directly. The parameter is not interesting, it is just a string.  There is another variable, which is a stub, but it's not used inside playback. There is a 'record' section, set aside with 'using' and not (thankfully) a #region. In the record sectio...

On the television as I type this is a show called "Amazing Wedding Cakes", which is unsurprisingly about cake making. In the current episode a bride has ordered 190 individual single-serving cakes. The team is struggling with a trade-off between doing the work on time and doing the work really well. We all do that. Software is so very much the same. We simply don't have time to obsess on every detail, but we also can't skimp on essential details. We need to make both radial and linear improvement, but we can't abandon our charter to deliver quality. This has been a running meme this week, whether one can afford quality and whether skimping quality will help a team go faster.  I've gone on record enough times saying that I don' think you go faster writing poor code, and I echo Uncle Bob Martin in saying that our most significant impediment is the bad code we have to work in. In the end, the boss was pretty angry about the care that was taken with each...

Today we didn't make a lot of linear progress I think of quality in two ways.  One is the product quality that users perceive, and the other is the habitability of the code itself. One says whether the function points and UX are well-selected, and the other says whether it is worth your time to try to work in the code.  One can have crap code that seems great externally, and one can have beautiful code that doesn't do anything a user is interested in doing (the popularly presented dichotomy). Likewise one could have poor functionality written poorly, or great functionality written well.  Those who consider themselves professionals in software craft will desire great functionally written well. I often get to work in code that started out as good functionality badly written. I get to work on the teams that clean up the mess and make the system more useful, scalable, and performant. As we work, the code gathers external quality. It becomes increasingly virtuous .  S...

We say "embrace change" and "accept changes to requirements, even late in the process."  We also rant about focus and that developers should neither be interrupted nor allowed to multitask.  To a lot of people, this sounds just like a contradiction.  Are we hypocrites? There is no conflict in these statements. The problem is with the organization. Change In A Change-Resistant Culture If, for example, I plan a release in 10 months, and assign each of my developers a ten-month task (or a couple of five-month tasks) then I am not only at capacity, I'm likely well over and don't know it. Now, in month two I have a change I would like to see. I can't get any of my developers to put aside their work and take my task.  Those obstinate developers!! What's wrong with them?  Nothing is wrong with them.  They are doing the work they are assigned, and since they have no slack or reserve capacity they know that the new task puts their release in jeopard...

I wake up with odd memories. I think my brain is just getting exercise, staving off senility maybe. Yesterday I woke with a memory of a bug fix from long ago, probably 15 years or more. I was given a project which led me into the permissions-checking code of a billing system. When I got there, I saw the code was written in such a way as: permission* perm = GetPermission(thisPerm); if ( perm != null && perm.Allow == false) { return false; } return true; I know that's silly, but I am recreating from an old memory, and I remember the code having some silly uses of null & the like. I remember noticing right away that if a permission did not exist, it meant that the user can perform the activity. GetPermission() read from a database table, I think, so that all a user had to do to get unlimited access was to drop records from a table. Furthermore, if an installation tech didn't deny access to unpaid features, the customer got them for free. I don...

I'm talking to users of statically-typed languages today. Functional and dynamic language people, cut them some slack and realize I'm not talking to you. Breaking with Conventional Wisdom There are certainly Object-Oriented design pundits who will argue that you should never, ever have public variables in a class. The reason is good enough, that the object should be responsible for its own state. You should tell it to do things, and it should do them. Likewise you should not manipulate its variables for it, since that requires a strong understanding of valid states for the objects, and this understanding is a strong coupling. Strong couplings between classes are bad things. All of that wisdom is correct and proven. However, many programmers make bean-ish objects where every private variable has a getter and a setter. This helps to preserve uniformity of access (you can't tell if it's calculated or stored, method or variable), but is otherwise the same as exposing pu...

SOLID design FIRST -rate tests Virtuous code I understand the "just get it done mindset" because there is a lot of learning, thinking, and doing behind those three simple links. It is daunting. Any developer who can sling code could become considerably better at coding and more desirable as a teammate if he would learn and apply these concepts in his daily work, but it won't happen overnight. Jeff and I built these 3x5 cards and simple explanations on the web site, but we don't pretend that you can live on these sound bites alone. The cards tell you what the words mean, and that's a good starting point (better than winging it), but the part that matters most is the part that won't fit on a card, the part where one practices. I like the word "practice." Wherever you are writing code today, it is practice. You are expected to apply principled development and get better, but even if you are slap-dash hacking things together, you are building your ...