Somehow, sometime, the concept of a spike got introduced into agile practice and language. The general idea is this; we need to make a product change but aren’t quite sure what direction to take or how to find that direction in the first place. A spike is the black flag we raise to say we need time to work on something that isn’t _obviously_ productive. The end result should be information and a general idea of what we need to do next, not code and software in production.
The rules are simple, the implementation is not. What I usually see, is spikes that result in a day of reading API documentation. So, the question then, is when is it a good idea to spike something out and when might we be better served by digging into the work and learning from that experience?
The longer the function, the more complex it is, the more likely we are to make mistakes. Knowing that makes measuring code complexity, and making the complexity of functions smaller, seems like a very good idea.
So how do we measure it? The most common measure of code complexity is probably “cyclomatic complexity.”
So what exactly is “cyclomatic complexity?”
The definition both confuses me and puts me to sleep at the same time – and I’m a formally trained mathematician with coursework in graph theory.
Seriously, try to make sense of this. You can just skim; I’m going to give an explanation in English later:
The formula of the cyclomatic complexity of a function is based on a graph representation of its code. Once this is produced, it is simply:
M = E – N + 2
E is the number of edges of the graph, N is the number of nodes and M is McCabe’s complexity.
To compute a graph representation of code, we can simply disassemble its assembly code and create a graph following the rules:
- Create one node per instruction.
- Connect a node to each node which is potentially the next instruction.
- One exception: for a recursive call or function call, it is necessary to consider it as a normal sequential instruction. If we don’t do that, we would analyze the complexity of a function and all its called subroutines.
Here’s the Matt Heusser GoodEnough™ explanation of complexity, why it matters, and how sometimes, it doesn’t.
The October 2015 cover of Inc. Magazine featured Elizabeth Holmes, the pioneering CEO of Theranos. Holmes had discovered a way to take a hundred-plus blood tests in one – in a fraction of the time, from the prick of a finger instead of a vial-per-test. The technology even had the potential for home use, more like a at-home pregnancy kit than the wait-two-weeks lab tests that are the current state of the practice.
The only problem is that it wasn’t real.
None of it.
On her warpath to home-testing, Holmes raised 1.3 Billion in investment funds.
How did that happen? Continued »
According to Judea Pearl, a co-creator of the Bayesian Filter, today’s machine learning is just “curve-fitting.” That’s taking a set of data points and mapping it into a line. This can be incredibly effective at, say, predicting seasonally-adjusted demand in order to reduce excess inventory yet keeping the shelves fully stocked.
But is that really artificial intelligence?
Pearl says no, and that the applications for that kind of specific, directed Machine Learning are less than the you might think. Continued »
This story about mistrust was circling around one of the technology themed Slack groups I watch. The plot line is that a manager has an employee abruptly put in notice. She is upset about having a top team member leave, but also because she feels this person is not telling the full truth about why he is leaving. The story reads like an ‘Ask the editor’ type of column you might find in your local news paper. Not the paper for the city you live in, but maybe the town or neighborhood.
Someone in the Slack thread asked “Is anyone completely truthful with their employer”? The overwhelming answer was of course not. I am no because my situation is different. But, when I was employed by a company, and if I am ever again in the future, I’d be a ‘no’ too.
Here’s a little story about a time I put in notice to explain why I have always kept things back from employers.
Imagine for a moment that you step into a therapists office, complaining of stress. You ask what to do and the therapist asks you for your ideas. You suggest running, watching a ball game, taking a nap, having a few beverage with friends, talking a walk, or watching TV. The therapist replies “It sounds like you have some good ideas.”
Today I’m going to talk about a totally different way to manage stress. Continued »
A few years ago I was on an overworked team. Big surprise there, right? We were working on a long list of work for an upcoming release. We through everything was documented in our bug tracker, but you know software, the more you dig into the work the more new scope you discover. We would work on a change, and discover that there were hidden requirements, or that the code base was a rats nest that had to be addressed before we could actually get work done.
Our development team usually took care of this by either documenting the new scope in a card and getting it queued up for future sprints, or they would get the changes done at night or on the weekend without it ever hitting our bug tracking system.
Sometimes this was good, sometimes it wasn’t.
One of the roles I play in the little software communities I belong to is a bit of an ambassador. I am approachable, easy-going, and tend to flit about between communities. If people feel like they don’t “belong” at a “Agile” event, a “Test” event, or a “DevOps” event, they might know me, and feel a little bit more comfortable. One of the ways I do that is through Lean Coffee.
At its heart, lean coffee is a way to put just enough structure around a meeting with no formal agenda. In about an hour, a group of strangers can meet, align on what to talk about, help solve each other’s problems, and leave as … something more than just strangers. As a conference speaker, it has been my pleasure to run Lean Coffee at over a dozen places over a few years.
The format is deceptively simple. Here’s how to run Lean Coffee in one image, created by Gerry Kirk, who I met at Agile&Beyond in 2015 and used with permission:
Five or so years ago I was working at an early stage startup in the anesthesiology space. We were making a product for anesthesiologists to document cases in real time that would help them navigate away from traditional pen and paper solutions. The development team I worked with was building and delivering software one week at a time. The business was inventing and designing software 6 months to one year at a time. Once a quarter or so, the company would get together and listen to a meeting about our product road map. This told us about the customers that were important, and what software changes they would need over the next 6 months.
Seems nice to have that much certainty, right?
Yet many of the individual teams I work with don’t see benefit from SAFe. The pertinent questions seem to be: What problems does SAFe Solve – and do you have those problems? Continued »