Agile Otter Blog

Eric Ries has suggestions on why/how to move your engineering practice forward and gain speed and reliability while you're at it: So how can I help the engineering manager in pain? Here's my diagnosis of his problem: He has some automated tests, but his team doesn't have a continuous integration server or practice TDD. Hence, the tests tend to go stale, or are themselves intermittent. No amount of fixing is making any difference, because the fixes aren't pinned in place by tests, so they get dwarfed by the new defects being introduced with new features. It's a treadmill situation - they have to run faster and faster just to stay at the level of quality/features they're at today. The team can't get permission from the business leaders to get "extra time" for fixing. This is because the are constantly telling them that features are done as soon as they can see them in the product. Because there are no tests for new features (or operational...

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...

Mike Pirnat found a snippet of python code. I can only suppose it was written as a joke. Python is such a readable language left in something approaching a "natural" state. This code looks like an entry in the old C obfuscated code contest. It uses a lot of the same tricks they would use back then, though we don't have any way of writing proper macros. It could have gotten much worse if they really wanted to stretch with lambdas, comps, generators, localizing methods, misusing decorators, etc. Personally, I think it's a great example of how important naming and tidiness are. If you can make a great language like python look like a load of manure, then imagine how "clever" programmers can do evil in languages like C++, Java, or even Ruby. Bad code is a matter of intent (or default, in some cases). Good code is intentional. All our code should not be joke code.