20 August 2019

Who should go on journeyman tour

Reisender Geselle im GebirgeIn our recent, bi-weekly software engineering podcast we talked about my Journeyman Tour. In particular Christian wanted to know who should go on such a tour. We discussed for a while, in fact I was talking most of the time and interrupting everybody ;-) It was kind of a hard question and I had not thought about it before, some new ideas came up.

Listen to Developer Melange: Who should do a journeyman tour?

19 August 2019

Y U NO TDD

Y U No TDDDuring this year's GeeCON the crew organised an Open Space evening. (An Open Space is a self-organising meeting where the agenda is created by the people attending.) I participated and ran a session on the question why we are not doing Test Driven Development. (Y U No Do TDD?) I am running TDD trainings from time to time and wanted to get more insight where people are stuck with TDD.

Context
As I said, an Open Space is self organising, and only people interested in TDD attended my session. This is a typical problem of communities of practice - only people interested in the topic attend - which results in us living in a bubble. For example long time TDD practitioner Thomas Sundberg and Shirish Padalkar, lead consultant at ThoughtWorks, participated in the discussion. Depending on the background of each individual participant, my original question was understood as:
  • Why are you not doing TDD on production work at all?
  • Why are you not doing TDD most of the time?
  • Why are you not doing TDD all the time?
I collected the reasons not to do TDD during the session which I want to share here. Text inside quotation marks, e.g. "hi" quotes exactly what people said. While the previous three questions are slightly different, the reasons seem to be similar. I grouped the answers. I did not want to contradict or debunk these answers and have to hold back not to do so ;-)

Prototyping
I am "experimenting with something", the "expected outcome is unclear" and "it's only a prototype". Obviously these are valid reasons as Spikes are outside of TDD. These answers usually coming up quickly makes me wonder if they are kind of excuses sometimes. Experimenting with new libraries and APIs is covered further down, so what are we experimenting with? I worked with many developers who would agree that the expected outcome of their current ticket was unclear - because they did not take the time to analyse the story and understand the solution they were supposed to build? Additionally most of our prototypes go to production after all, don't they ;-)

Time Pressure
Another reason - given by some of my clients too - is their need to go fast: "I need to go very fast", there is "no time for that" and I "believe to be faster without it". While they might be wrong in the long term I understand the effects of pressure. One person made it more explicit, while he has no strong deadline, he said "I have a huge backlog, I am stressed". Indeed when I am extremely stressed, I find it hard to maintain a structured approach, especially if a lot of task switching is involved. Besides the needed skill to apply TDD under high load, much discipline is required to endure pressure. In such situations Strong Opinions and Dogma might help.

Missing the Bigger Picture
I am just "writing a script for myself". Maybe there is no need for automated tests when writing a one time script for myself. TDD has a testing aspect - and it has many other aspects like designing software, fast feedback and working incrementally. TDD is not only about testing. Some people miss that or have only partial understanding of the benefits or do not care for these benefits at the moment. The opposite reason is "because I know how the class will look like". Yes TDD is about software design as I said before, and I would like my class to work, too. Some people only want the fast feedback, e.g. using REPL based development and "looking at UI is faster".

Missing Priority on Testing
When starting with TDD, the testing aspect is most visible. After all we have to write a reasonable test first. For teams and organisations with low or missing priority on testing, people are "looking down on testing" and I got answers like "testing is a culture thing", "testing is not a first class activity" and "I am not asked to create a test by my project manager". Indeed it is hard to keep following TDD if it is looked down upon and if there is no time for quality work.

Avoiding Context Switches
There is a certain amount of context switching involved in TDD. Similar to Edward de Bono's Six Thinking Hats, we have different states which we have to be mindful of and which call for different actions. George Dinwiddie created a TDD Hat to show that. Maybe this switching is "not natural for some people". "I don't want to interrupt creative design with verification" and "I prefer staying in building hat and not change to testing hat". Similar one participant said that it is "easy to write code, harder to write tests, so I do it afterwards". I understand and there is certainly an urge to jump into the code and get hacking. I rarely feel that urge and I enjoy pair programming using the Ping Pong style because it enforces the separation of states without any (inner) discussion.

Missing TDD Skills
This is obviously the largest area and there is nothing wrong with not knowing how to apply Test Driven Development: Honest people just say "I can't do it". Many are aware of this problem and seem to be disappointed with existing material and/or look for more material to study TDD: "It is not taught at universities", "there are no good books" and "I am missing real examples". I know from my own experience that TDD is not easy to learn and some people are "scared for life after a bad experience" with it. Now the best way to learn TDD is to have someone show you while pairing with you. Even if there is no pair programming in your workplace, you can still experience it during a Coding Dojo or Coderetreat. Short of that, I recommend Kent's Beck Test Driven Development by Example, which is a short and excellent introduction.

New Language or Library
When discussing TDD and unit testing with a client, he said I "don't know the target technology" and "React is a new technology for us". I had to laugh. To me this sounded like "I got a car and know how to drive forward, but am not able to drive backwards." On the other hand I live at the dead end of a road and I see drivers working really hard to avoid driving backwards. Are they not able to do it? So maybe stopping halfway in the game (of skill acquisition) is natural after all. When working with some new language or working with an unknown API, I specially rely on tests to support me, these are Learning Tests.

It's too hard to test
I agree some things are harder to test than others. "Android is hard to test", "Vaadin is hard to test" and "some libraries are hard to test". (I have not worked with Android or Vaadin, I quote people.) We might need to know more about design to decouple things. This is definitely true for legacy code, as "existing code is usually hard to test". Some people see the root cause, like in "I don't know how to manage boundaries". In such situations we need (to know) more tooling. We definitely "need more tooling to test the UI" as UI is traditionally considered hard to test from a TDD perspective. Still, Steve Freeman and Nat Pryce, authors of Growing Object-Oriented Software Guided by Tests, always start their TDD (outer) loop with an UI test. GOOS is a great book and I recommend reading it if you want to go deeper into TDD.

It's too simple to test
If there are things which are too hard to test, there must also be things which are too simple to test, right? It is "useless to test, it is so simple" and it "makes no sense to test it". Maybe a better description is that it is "unclear what is important to test". From a TDD perspective no such things exist and I guess these reasons arise from the test after process, when looking at each public method and thinking how to test it. Further excessive test isolation, see Solitary vs. Sociable Unit Tests, will cause that.

Barriers to TDD adoption
Here is Matt Wynne's summary of Barriers to TDD adoption from a session during Lean Agile Scotland 2016. I recommend checking out the Twitter thread as Matt added detail discussions on temptation of fast reward, permission and safety to learn, "the egotist" and other reasons not covered by me.

Barriers to TDD adoption #lascot16 (C) Matt Wynne
What about test-induced design damage?
Maybe the only real reason not to do TDD is to keep the design integrity of your system. This idea was started back in 2014 by David Heinemeier Hansson, also known as DHH, and led to the whole Is TDD Dead? debate. DHH said that when using TDD code sometimes suffers tremendous design damage to achieve two testing goals: Faster tests and easy-to-mock unit tested controllers and that the design integrity of the system is far more important than being able to test it any particular layer. It is ironic that this never comes up during any group discussion or team interview. Probably because it is an expert level reason. If you followed the debate, DHH knew TDD, he used it for some time and liked it. And then, only then, did he know when not to apply it.

17 August 2019

In Memory of Ruby

Meet Ruby, our dog. Ruby was a Great Dane. If you are not into dogs, Great Danes are known for their size, being one of the largest dog breeds in the world. Great Danes are also known for their friendly nature and are often referred to as a "gentle giants".

Great Dane Ruby
Ruby lived well beyond the average lifespan of her breed of six to eight years and passed away last month with an age of ten. She died of old age in our arms. This was - and still is - a sad and painful situation which only dog lovers can understand.

(And of course, Ruby was named after the Ruby programming language, my favourite programming languages of that time.)

5 March 2019

Flashcard Madness: Learning to spell

Ben Talking To GrandmaDuring work I sometimes need to spell unknown words. These might be names, e-mail addresses, foreign words or technical terms. The situation might be on the phone or during mob programming sessions, where I am unable to write the word on a white board or a chat window.

Spelling can be complicated and needs practice (as seen in these Developer Melange recordings outtakes ;-). To avoid confusion and to spell consistently I settled for the ICAO/ITU/NATO Spelling Alphabet. As I recently fell into flashcards - hence the title Flashcard Madness - and I created a deck to learn and practice spelling. I use Anki digital flashcards. The apkg files can be used with Anki for Windows and Android and AnkiApp for Mac and iOS.

This deck for English Spelling contains cards for the English NATO Alphabet, e.g. question spell D is answered by Delta. I added some (recursive) spelling exercises to the end of the deck, e.g. question spell Delta is answered by Delta Echo Lima Tango Alfa. Because of "madness" I went on to create an additional deck for Austrian German covering Deutsches ├ľNORM A1081 Alphabet.

Download English_Spelling.apkg and Deutsches_Buchstabieren.apkg here.

22 February 2019

Flashcard Madness: The Little Schemer

On my journey into the Scheme Programming Language I am currently reading The Little Schemer (4th edition) by Daniel P. Friedman and Matthias Felleisen. I started reading because of it was recommended by different sources. It is a fun little book. Its style is quite unusual as it is written as a series of questions, which force you reflect about the content along the way. It repeats the same steps again and again - a reminder of recursive concepts - which is forcing you to practice the concepts you just read about.

The book introduces Ten Commandments and Five Laws for the Scheme style of programming. The commandments are basic rules of working with lists and the laws define the API of used functions. Ray Grasso collected all the commandments and laws in his notes. What to you do when you have a list of rules? You study them! I like using flashcards to study short facts and created a set of digital flashcards for the Ten Commandments and Five Laws. The deck is in the Anki file format (apkg), which can be used with the Anki application under Windows and Android. There is a similar application AnkiApp for Mac OS and iOS.

The deck contains questions about the rules themselves, e.g. What is the 2nd Commandment? With answer use `cons` to build lists.. Then I derived questions which are more actionable, e.g. When recurring on a list of atoms, `lat`, ask two questions about it? With answer `(null? lat)` and `else`. I am not sure these cards are useful on their own, but they definitely helped me to commit the facts I learned from the book to my memory.

Download The_Little_Schemer.apkg here.

23 January 2019

Scheme Runtime and Editor Choices

Last month I wrote about my journey into the Scheme programming language, its standards and complete list of its special forms and functions. Today I want to describe some Scheme implementations I used as well as lightweight tooling to get started.

Scheme Runtimes
A nice thing about Scheme is its availability. There are many Scheme implementations and often many are available on different platforms. I started out using Gambit Scheme. I do not remember why I chose Gambit. It is certainly not the most popular one, which - according to questions on StackOverflow - is Racket. (On the other hand, Racked is much more than Scheme.) I guess I took what came up in one of my early Google searches.

if muybridge could bark (maybe a long shot but hey this dog is running)Gambit Scheme
Gambit is an R5RS compliant Scheme written in C. It is easy to install, mature, stable and under active development on GitHub. It is available for MacOS and Windows. Download it here. Besides the standard functions, it offers some SRFI- and many non standard ones for IO, threading and synchronisation, additional data types like signed and unsigned integer vectors (SRFI 160) and much more. Gambit comes with both a Scheme interpreter (gsi) and a compiler (gsc). The compiler transpiles Scheme into C which is in turn compiled using the GCC infrastructure (which must be in your PATH). The pre-compiled binary interpreters can be deployed as single EXE files. Yes, now I am able to write low level C code without knowing C. Win!

Gambit works well and I had no problems getting started. I recommend it to get started. While playing around with it I followed the same approach as last time and scraped the documentation for all available functions. Only later I found these lists provided by Gambit itself: R4RS and R5RS as well as all forms and functions provided by Gambit. There is a lot of documentation, which I still plan to read.

IronScheme
Then I found IronScheme. Like IronPython and IronRuby, IronScheme is a Scheme implementation based on the Microsoft DLR (i.e. the Dynamic Language Runtime). Most of its code just delegates into the CLR (i.e. the .NET Common Language Runtime). For example string-contains? is defined as
(define/contract (string-contains? str:string sub:string)
  (clr-call String Contains str sub))
IronScheme supports compilation, too. Now I can write native Windows applications without knowing anything about .NET. IronScheme is (by its own definition almost) R6RS compliant. Because of the added complexity of R6RS modularity I have not used it as all my Scheme work consists of toy projects. For real world application modularity would be the way to go.

I could not find any pre-build releases of IronScheme. To get the latest build go to its AppVeyor page, select the first build job (probably Environment: FX_VERSION=v2.0) and open the Artifacts tab. After downloading and unpacking the ZIP, the Scheme library code has to be compiled with ngen-all.cmd and echo (compile-system-libraries) ^| IronScheme.Console32-v2, yielding 10MB of DLLs.

Kawa Scheme
There are several Schemes available for the JVM (i.e. the Java Virtual Machine). One of them is The Kawa Scheme language which supports R5RS, R6RS and R7RS. I have not used Kawa. And of course there is Clojure which is a dialect of Lisp and somehow similar to Scheme. But Clojure lacks tail-call optimisation, which is required for Scheme implementations.

Mobile Devices
There are Schemes for mobile devices, too. Gambit builds a version for iPad and Android has several Schemes, e.g. Simple Scheme. So if you ever have been away from your computer and thought, "Boy, I wish I could be writing Scheme code right now" - well, now you can!

A lightweight process supports learning
I still have not read much documentation on Scheme besides SICP which uses basic language concepts so far. I am just playing. The lightweight process I am following is keeping up the fun and supports my learning:
  • Scheme has this minimalist design philosophy. I really like its simplicity. I am never stuck on syntax, reserved words or edge cases. And there are no semicolons. ;-)
  • R5RS is the Scheme to start. It is the most widely implemented standard and most documentation and StackOverflow answers apply.
  • The Scheme runtime must be easy to install and should not mess up my system.
  • I favour runtimes that are available for different architectures and operation systems so I can use the same runtime on different machines, e.g. on my main x64 workstation, my legacy x86 netbook and even my tablet. Especially when having fun with learning, the device should not be limiting me.
  • An interpreter usually starts faster than a compiler which is important for my trial and error approach. The Gambit interpreter starts fast and I use its REPL to explore the language often.
  • A lightweight editor. Emacs would be the traditional editor operating system to work with Lisp languages and I know at least one Clojure developer who uses it. I have never used it and while getting into Emacs would be a cool and fun thing to do - long overdue according to my learning list - I do not want to post phone my Scheme experience. Any text editor should do. I will talk more on editors later.
Colour Out of FocusUltraEdit Syntax Highlighting and Tool Integration
I met UltraEdit 15 years ago and still use it as my main text editor. I guess I am old-fashioned as my version is 8 years old. Before going full scale with Emacs, I wanted at least some syntax highlighting in UltraEdit. Adding a configuration for syntax highlighting is simple (and I have done it before.) With the complete list of forms and functions I created a UltraEdit wordfile for R5RS/Gambit Scheme and one for R6RS Scheme. As soon as UltraEdit knows about the structure of Scheme, it provides code completion and shows all functions defined in the current file.

In the tool configuration I declared a tool to run the current Scheme file (command line gsi "%f" with working directory %p). UltraEdit has a shortcut to select groups of parenthesis (CTRL-B) which is very handy when working with lots of parens.

The next thing I missed was auto format. Formatting is important to keep code readable. Automatic formatting is important, because it saves work and it is easy to overlook a missing blank or newline. So I created my own Scheme-Formatter.

What about a real IDE?
Eventually UltraEdit became too "small" for my Scheme project. It works well for single file scripts but I the navigation between files is limited. So I switched to Visual Studio Code with the vscode-scheme extension. Code is nice because the navigator enables fast navigation and version control is integrated. I can commit and diff without switching windows. I mostly use search and replace across all files as it is my main refactoring tool. In the end, Code is just another editor. It is not an IDE like Eclipse or IntelliJ is for Java. The Scheme extension provides syntax highlighting but the editor's auto indentation always screws up the formatting.

Conclusion
Restarting development with a new language in a new environment was amazing. As the project grew I (obviously) had to learn more and more things. For example - because of the size of the code - the next thing I wanted was to navigate to the definition of a function. Enter Ctags. Ctags supports Scheme out of the box and both UltraEdit and Code are able to use the generated tags file. Of course Emacs does as well. Maybe I need to go for Emacs after all.

10 January 2019

Interview Hanno Embregts

I am happy to start the year with another guest interview on ethics in Software Development: Hanno Embregts is a developer, teacher and frequent speaker from the Netherlands.

Hanno, how did you become a software developer?
Just before I graduated high school I was fairly certain I would end up in Economics. During college I took a few Computer Science classes on top of my Economics curriculum and I quickly discovered I liked programming a lot more than analysing micro-economic models. The concept of creating something new instead of just rehashing other people's ideas really appealed to me. The rest is, as they say, history.

I have been a software developer for over 11 years now, and I still love it immensely. I have worked on for about 10-15 clients, including insurance companies, banks, health care and public transport. I have spoken at 12 international conferences, while actually enjoying it. I used to be terrified of public speaking when I was younger, but it seems I gradually got used to it. Doing something you are quite comfortable with in front of an audience (in my case: playing music and singing) really helps you to get used to 100 pairs of eyes staring at you.

I saw you discussing ethics in software development on Twitter. Why does that matter to you?
Much of it has to do with my Christian faith. As a Christian I try to follow the example that Jesus Christ set when he lived on the earth. He devoted his time mostly to doing good for the people around him. And he specifically noticed the people that were less important in society. So I try to do the same, both in my private and my work life.

Women Baker In BadakhshanWhich topic are you most concerned about?
I am very concerned about the gap between the rich and the poor people. The rich are getting richer, and the poor are getting poorer. And although I can consider myself fortunate that I was born in a rich country with a lot of possibilities for education and career, I realise I could have been a lot less lucky. And if that would have been the case, I would want the rich people to help me out.

I try to share my assets with those who are less fortunate. I am quite enthusiastic about Kiva, a lending platform which supplies loans with low or no interest to boost local economies. Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime.

What do you consider the biggest challenge for humanity?
I think our biggest challenge is to love each other. Not just those who are special to us, but more importantly the other people: Your neighbours, your colleagues, even your enemies. If everyone would do this, there would be no need for wars and conflicts. Food, money and other assets would be distributed more fairly.

When I talk to people, many express concern about meat mass production or pollution. What could we do to engage in the topics?
Caring about the planet is important, because it shows you care about future generations. No-one can solve this problem on their own, but I try to contribute through a few small things in my life. I eat less meat than I did before, and I go to work by bike whenever I can. I moved my financial life (bank accounts, credit card etc.) to ASN Bank, which invests in socially responsible and sustainable projects only. And every month I donate money to Trees For All, an charity organisation that plants trees all around the world. As I said it does not solve the problem instantly, but it makes me feel good and gives me hope for our future.

I am looking for more impact on important topics while doing my regular work. Do you think that is possible in general?
I need to keep working in software development, because I love doing it and I cannot imagine earning my money in any different field. And there are not many jobs for software developers that directly change the world in a significant way. But that does not mean I cannot make an impact. As is pointed out in Episode 7 of the excellent podcast Soft Skills Engineering, somebody has to write the mainframe app that the bank uses so that charities can use this app to change the world in a significant way. And an insurance company has to insure the charity that produces clean water in underdeveloped countries. It may be directly or indirectly, but we are bound to make an impact in the world.

We take many decisions during projects. Which guidance do we have to navigate these decisions?
While I am developing software I try to think of myself as the end user. Would I feel comfortable with my decisions if I had to use this software on a daily basis? Would I find it acceptable to permit this app to access my contact list? Would I be happy when a website after creating an account immediately registers me for an email newsletter that I have not explicitly signed up for? Asking myself these questions nudges me in the right direction more often than not.

How do you think about selecting industry, customer or project based on your values?
I think if you have the chance to choose a project that clearly improves the world in a profound way, then obviously you should go for it. I have worked on a few medical software projects and the fact that my code helped medical staff to cure people motivated me immensely. At the moment I am working on public transport software, where the goal in itself is entirely different. I find that my motivation focuses on different things now, for example on teaching some junior developers the tricks of the trade.

FMSC Distribution Partner KenyaLet's be more specific: Would you work for an animal factory? Would you work for a company producing equipment for an animal factory? Would you work for a sweat shop exploiting kids in Asia?
I would not work for any of them. As I wrote earlier I am a big believer in sharing things equally over all people, so any company that violates human rights, exploits kids or does not pay fair wages is a no-go for me - both as a consumer and a software developer for that matter. This in itself is a challenge to say the least, because how do you find out which industries are OK according to this definition? Sure, there are a lot of certification labels that can help you decide (such as UTZ, FSC, Fairtrade), but every once in a while I read stories about these labels that really disappoint me. So I try to do some research on these industries to get to an informed decision.

That being said, there is also a 'grey area' of companies that I might work for, but only if there is no better alternative. For example, I am a big believer in electric- and hydrogen-powered cars. But I might consider working for Volkswagen or Mercedes anyway. The clothing industry is another good example. There are brands that pay their people fairly and there are those that exploit their workers. But there are also a lot of brands 'in between'. I might consider working for them. Who knows, I could perhaps help them to become a fair-paying brand.

Did you ever reject a client or project based on your values?
I have not, actually. But as I wrote before, in theory there are a lot of projects that I would reject based on my values. I think it has not happened until now, because our industry is booming and there are job openings everywhere. So because of that I have so far been able to choose projects that match my values fairly easily.

On the other hand, what would be projects that you would love to work on?
As I mentioned I work in public transport for a while now, and I like the fact that the train company in my country uses renewable electricity only to power their trains. I might work in the finance industry again and if that happens, I would be really interested to work for a socially responsible bank. Also working for an NGO would be interesting I guess. Still, I like what I do now and from teaching junior colleagues and sharing knowledge at various international conferences I derive a lot of meaning. Perhaps they will use the things I have learnt them in the future when they work at a socially responsible bank or an NGO. It may be directly or indirectly, but we are bound to make an impact in the world.

Thank you Hanno.