Jonathan Levin's Axioms

In the UK, tax prices have gone down from 17.5% to 15% .

Yes, I have turned into the stereotype called a scrum-master. I haven't really done the infamous 2 day course on it to be certified, but apparently I read enough about it and practiced some of the principles to know a few things (or at least to think I know).


In my company..

In my company, we do use scrum with our development team. In most cases it works very well and the management are very happy. In some cases, where emergency support is involved, not so much, but they still like the structure of it and the fact that people commit to finishing things.

In all cases, very little testing is being applied and almost no documentation is written. I do realize that in the case of documentation, agile is suppose to cut down on those, but some form of documentation or changing some charts will be fine by me. In the case of testing, I think since I made a fuss about it, more testing has been done. But, I still think we could do much more about testing.

I spoke with my boss about it and how he looked at it was that, we had applied a process that brought in positive results and now we are at the next stage where we evaluate some of the problems that rose to the surface. Meaning, we are doing so well that we are fine tuning the process. I tend to agree with him on that. Even though technically, scrum does say that you need continuous integration testing, most places I have seen have been struggling with the testing sides of it. Oh, I did the self assessment on the nokia test and got a 5 out of 10.


Oh noes!! we must write tests now!

To be perfectly honest, its quite difficult to sell people on the idea of testing in general. Sometimes, when I mention testing, everyone thinks I am talking about moving everyone to test-driven-development. So in any case everyone is scared I am making earth-shaking changes to the whole process they are used to.


The (slight) Downsides of Tests

Tests themselves have issues that you need to maintain them. If you write a test with very specific parameters and values and then one day you change the actual behavior of the code, you will need to re-write your tests. You can avoid that by making your tests flexible for those changes, but you need to be aware and somewhat experienced in testing to do that.

Also, when you develop something new, writing tests can be much more simpler then writing tests when you are trying to fix old code. That is something I am particularly struggling with, since a lot of the work we need to do is patchwork to existing code. Just to add tests to existing code means you have to go into it, understand it and then apply some tests to it.


Conclusion

I need to study the issue more and try to apply it to my teams.
In any case, we need more testing and documentation (documentation is something I also plan to write about).

What I have decided to do is to try to do some of the following things:
1) Add certain tests as a requirement on the user stories
2) Do user stories that the whole process is to write tests for a problematic part of the code (the 20% of the code that causes 80% of the problems)
3) Do a face-off between 2 teams. One will use TDD and the other one won't. This will be a proof of concept that TDD is faster to develop then with regular development or even it is slower, only marginally slower and has the addition of all the extra tests.


Here are some questions I have asked on stackoverflow:
How do you apply Scrum to maintenance and legacy code improvements?
Scrum, but with no testing or documentation

I was looking for some non-windows machines for my development team. My development team all use Ubuntu. As hard as I tried, I couldn't really find anything pre-built that didn't have windows on it. 

I have been doing some studying on the internet in my free time (not that I have too much of that nowadays) and I stumbled upon the Unix Philosophy. This is a philosophy, not method, for building programs and systems.
As I went through the rules, I found something interesting. I'll paste it here:

Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust.

Even the simplest procedural logic is hard for humans to verify, but quite complex data structures are fairly easy to model and reason about. To see this, compare the expressiveness and explanatory power of a diagram of (say) a fifty-node pointer tree with a flowchart of a fifty-line program. Or, compare an array initializer expressing a conversion table with an equivalent switch statement. The difference in transparency and clarity is dramatic. See Rob Pike's Rule 5.

Data is more tractable than program logic. It follows that where you see a choice between complexity in data structures and complexity in code, choose the former. More: in evolving a design, you should actively seek ways to shift complexity from code to data.