Apropos very little, in a recent conversation it was suggested that testing is waste from the perspective of the business. My immediate reaction was visceral opposition to that line of thinking.
After some consideration it occurs to me that the assertion that Testing is Waste must be wholly incorrect. Here's how I got there.
First, if I ask you to build me a Flux Capacitor, how do I know I have one unless I test it? That is, testing is the validation that tells me as a product owner that I have received what I asked for. No waste there.
Second, if I'm making a Flux Capacitor I must have some means of knowing that what I've built does what I want it to do. I'll have to test the device to see if it qualifies as a Flux Capacitor.
So, in order to build the Flux Capacitor, the engineer building it must conduct some tests to ensure that the thing built behaves like a Flux Capacitor. In order to receive a Flux Capacitor, as a product owner, I must conduct some tests to verify that the device I've been given is a Flux Capacitor.
Therefore, testing isn't a waste, it is a necessity.
18 September 2017
15 September 2017
Idioms, Standards, and Conventions
Finally, a blog with more than a one word title.
Today we had some conversation about standards on our team. I think it was a good conversation. It got me thinking about idiomatic use of platforms.
Did you know (technically) idioms are not standards?
I'm all for idiomatic use of tools, platforms, etc. Doing it like others is a good thing. Convention over configuration, etc. etc.
That said, there are occasions where you need a standard. Just because your agile doesn't mean you can't have some kind of rigor.
It is important for every team to figure out what standards they need, and each team is bound to be a bit different. It's also important to follow the standards if you have them. Having them and not following them is a bit of a waste.
Lastly, like all other things, you should periodically question why you have a standard and if it is still appropriate and/or needs to be changed, updated, or removed. As we learn more about what we're doing our needs usually change and sometimes our standards need to change with them.
Today we had some conversation about standards on our team. I think it was a good conversation. It got me thinking about idiomatic use of platforms.
Did you know (technically) idioms are not standards?
I'm all for idiomatic use of tools, platforms, etc. Doing it like others is a good thing. Convention over configuration, etc. etc.
That said, there are occasions where you need a standard. Just because your agile doesn't mean you can't have some kind of rigor.
It is important for every team to figure out what standards they need, and each team is bound to be a bit different. It's also important to follow the standards if you have them. Having them and not following them is a bit of a waste.
Lastly, like all other things, you should periodically question why you have a standard and if it is still appropriate and/or needs to be changed, updated, or removed. As we learn more about what we're doing our needs usually change and sometimes our standards need to change with them.
13 September 2017
Myopia
I just wrote a rather lengthy post in trying to get to the following post. There was some useful catharsis in that process, but I think the salient part is this;
When we are developing software and we recognize a feature but do not fully understand it in the context of the entire system it is incumbent upon us to learn its meaning in the full context of the system before we discard it as unnecessary. Without this context and understanding the consequences of not implementing the feature are unknowable to us.
Similarly, when we plan and approve work we must keep in mind the larger picture. We cannot fail to implement a feature or approve work that fails to meet a specification out of expedience. Undelivered system features fight for primacy until they are delivered. In considering a feature set in its entirety it is relatively easy to determine which problems to tackle first, however, closer to the metal the issues can become indistinct. We must remember to back off and look at the larger picture before we discard something.
Some features require a large number of individual parts working in concert to achieve a target behavior. Failure to deliver one of those parts leads to a failure to deliver the feature itself.
If we develop a myopic view of our systems we will fail to recognize when we underserve macroscopic features of an overall system.
When we are developing software and we recognize a feature but do not fully understand it in the context of the entire system it is incumbent upon us to learn its meaning in the full context of the system before we discard it as unnecessary. Without this context and understanding the consequences of not implementing the feature are unknowable to us.
Similarly, when we plan and approve work we must keep in mind the larger picture. We cannot fail to implement a feature or approve work that fails to meet a specification out of expedience. Undelivered system features fight for primacy until they are delivered. In considering a feature set in its entirety it is relatively easy to determine which problems to tackle first, however, closer to the metal the issues can become indistinct. We must remember to back off and look at the larger picture before we discard something.
Some features require a large number of individual parts working in concert to achieve a target behavior. Failure to deliver one of those parts leads to a failure to deliver the feature itself.
If we develop a myopic view of our systems we will fail to recognize when we underserve macroscopic features of an overall system.
11 September 2017
Burnout
Stewing in the back of my mind are thoughts about burnout. I have been know to get burned out periodically. Usually a mental-health day is all it takes to get back on track. Sometimes I need two. Typically what I need to do is find some other problem set to work on. Just something to let me know there is another class of problem to work on, assure me that I'm not trapped in Dante's Inferno someplace.
An observation, some people accept burnout. That is, they get burned out and they just keep marching forward. I think this leads to a complacent attitude. It allows you to become dull witted and you loose effectiveness. It's important to guard against that and to find a way to get through it.
An observation, some people accept burnout. That is, they get burned out and they just keep marching forward. I think this leads to a complacent attitude. It allows you to become dull witted and you loose effectiveness. It's important to guard against that and to find a way to get through it.
06 September 2017
Zombies
I was supposed to post about test driving regex today. I failed. I've become very busy, and that is making it hard to get posts with code done. I'll try again for Friday.
While you are waiting, I have something to say about Zombies. I saw a tweet today about Scrum;
I'm not dissing Scrum per se, but what I am saying is that normalization for the sake of normalization is bad. Normalization should be in the eye of the beholder; a team should find a norm that works for them and use that to their advantage. Please don't get hooked on someone else's normal.
Every team should develop practices and procedures that work for _them_ and _not_ use any practices or procedures that _don't_ work for them.
Don't be a Scrum Zombie!
While you are waiting, I have something to say about Zombies. I saw a tweet today about Scrum;
Consider this, by normalizing the social DNA of your team you are creating Zombies. As we all know, zombies are bad. Zombies are scary. Zombies eat your brains!#Scrum normalizes a team's social DNA: builds better accountability, collab, & trust norms w/in team ^ @SocialAgilist pic.twitter.com/3EBOE6kHNO— AgileFortune (@AgileFortune) September 5, 2017
I'm not dissing Scrum per se, but what I am saying is that normalization for the sake of normalization is bad. Normalization should be in the eye of the beholder; a team should find a norm that works for them and use that to their advantage. Please don't get hooked on someone else's normal.
Every team should develop practices and procedures that work for _them_ and _not_ use any practices or procedures that _don't_ work for them.
Don't be a Scrum Zombie!
01 September 2017
So I Was Working On It
I was working on a post about using TDD for Regular Expressions. I've run out of time. I'll work on this over the weekend and hopefully have a good example of how you can get good coverage around a regex.
Considering the Labor Day Weekend, look for a post on Wednesday of next week on the topic of Test Driven Regex.
While you wait, consider that regular expressions are a super powerful way to parse strings. That said, I like to joke that given a parsing problem you can find a regular expression. Now you have three problems.
Regular Expressions can be very challenging to learn and can often be very fragile. That said, they provide a concise means of parsing complicated string data into something you can easily use.
Working on my example of how to TDD a regular expression I came up with this simple (and still somewhat dumb) regex for at least one form of ISO 8601 Date-Time strings.
Using the Python re library, this regex will quickly chop up a date-time string. This is kind of silly since there are plenty of date-time parsers in the world; I picked this example because its still reasonably simple.
In any case you might find yourself in need of a custom string parser and regex is a great way to get there. Doing it with tests can be challenging though. There are lots of funny edges to be considered.
So, if all goes well, I'll have an example for you next week. Until the, enjoy the holiday.
Considering the Labor Day Weekend, look for a post on Wednesday of next week on the topic of Test Driven Regex.
While you wait, consider that regular expressions are a super powerful way to parse strings. That said, I like to joke that given a parsing problem you can find a regular expression. Now you have three problems.
Regular Expressions can be very challenging to learn and can often be very fragile. That said, they provide a concise means of parsing complicated string data into something you can easily use.
Working on my example of how to TDD a regular expression I came up with this simple (and still somewhat dumb) regex for at least one form of ISO 8601 Date-Time strings.
'(\d{1,4})-(\d+)-(\d+)T(\d+):(\d+):(\d+)\.(\d+)(.\d+:\d+)'
Using the Python re library, this regex will quickly chop up a date-time string. This is kind of silly since there are plenty of date-time parsers in the world; I picked this example because its still reasonably simple.
In any case you might find yourself in need of a custom string parser and regex is a great way to get there. Doing it with tests can be challenging though. There are lots of funny edges to be considered.
So, if all goes well, I'll have an example for you next week. Until the, enjoy the holiday.
Subscribe to:
Posts (Atom)