I heard about F# Koans on a recent episode of .NET Rocks and went to check it out. It is a series of little bite sized F# tutorials. Koans are a great way to teach a language. The little independent chunks of functionality get wrapped up in a little test to complete to show you understand. I picked up a few specific F# things from it.
- Multiple types in discriminated unions example
- type Favorite =
| Bourbon of string
| Number of int
- Seq is IEnumerable, which explains why it can have deferred execution but doesn’t always
- Arrays are the .Net arrays and that means they’re mutable
I also got some broader insights as well.
- Seeing code using classes and modules helped me better understand the scoping issues I was having with them writing them on my own.
- Looking through all of the code that was designed to run the system since it showed off some other F# that wasn’t covered before like annotations and reflection.
I still haven’t written code with the backwards pipe operator <| but reading code using it makes me want to refactor what I did write that way and try to get there. I think it’s much clearer in terms of readability. I’m not sure how to overcome my natural inclination toward the forwards pipe operator or parenthesis and instead write the code I want to read the first time.
I had not thought a fill-in-the-blank style of application would work with a compiled language since you couldn’t run each chunk without having done all of the exercises. But this application worked around the type system to create code that would compile but was clear that you needed to fill in the blanks. I liked the koans for learning purposes since I could pop over to do a couple in a quick burst. I also liked that it had exercises that asked you what a provided code sample did, as well as ones that asked you to write code yourself to achieve a specific result, not just one or the other. It took me about two hours to do all of the exercises so go ahead and check it out.
Everyone wants to produce good software, free from technical debt. Often the goal of producing good software conflicts with the economic reality of building software and compromises get made resulting in technical debt being taken on. Knowing whether you need to make a compromise on quality to achieve a goal, if you can achieve the goal with quality, or if the goal itself is flawed is difficult. You need to understand the goal and what you can actually accomplish in order to determine how to proceed.
Programming, Software Engineering and Computer Science are three obviously interrelated disciplines, but people often use the terms somewhat loosely. In particular, people seem to use programming and software engineering interchangeably and it dilutes the differentiation between the two. People go to school for Computer Science then get jobs as programmers, developers and software engineers, which muddies the differences further. I want to try and differentiate how I see the terms.
I recently read The Checklist Manifesto by Atul Gawande. The centerpiece of it was the case study of a checklist to prevent post-surgical issues. It was just some simple questions to be asked (1) before anesthesia, (2) before the first incision, and (3) before the patient leaves the operating room. Really simple things like what procedure is to be performed and the name of the patient.
You would think that since surgeons are highly trained specialists and everyone is highly motivated to save patients, that this simple list wouldn’t help much. But it prevented a third of post-surgical complications. Everyone knew you should do these things, but they were being overlooked or abbreviated. Putting steps in writing also empowered the nurses who had previously felt intimidated to speak up when they saw something go wrong, since they had a standard to hold the surgeons to.
By now you are thinking “that is interesting and all, but what does it have to do with software development?” Well, it made me think of an agile team agreement. The agile team agreement is a written plan for the team to do the work it has ahead of it and what is expected of team members, i.e., a checklist. A user story is supposed to meet certain criteria before being considered, then to be done with it you need to meet other criteria. Agreements help keep you from skipping out on the steps needed to build in quality that you know you should be doing but sometimes skip for simplicity or expediency. They also makes it ok for the rest of the team to call out someone who wasn’t meeting the standards you all agreed upon at the outset. The places I’ve worked that used team agreements felt like they worked better than those that didn’t.
That’s a gut feeling, and unfortunately, we don’t have hard quantitative measures for software quality to match the medical example. Qualitatively, I felt like we accomplished more with less, and built better software. We definitely had a better time doing it which was just as important.