10/18/15

Standup

Recently I was asked if it makes sense to do standups. Is it just a formal waste of time? Wouldn't it be more useful to spend the same amount of time by actual work?

This is how our standup looks like, this is how the work would look like without it according to me and this is why I think it's worth doing standups:

Standup optionally starts with a half-minute long announcement by the Scrum Master if somebody is missing and when will be this person available again.
Without standup: We could check out this information from a well-prepared shared calendar but unexpected lates or illnesses which are missing from the calendar would require a little bit more communication and irrelevant discussion during the day. It would cause some delay for sure.

Then we look at the burn-down chart of the sprint and to the status of the latest nightly build. Is it stable, what about automated tests which were run last night? We make a common standpoint in one minute which is clear and acceptable for everyone. Are we good / are we late / do we have unexpected problems? If we can't come to the same opinion, optionally a new meeting can be scheduled after the standup, but it's quite exceptional. It happens when the test result is very bad or our progress is excellent and we tend to run out of tasks.
Without standup: we would look to the burndown chart and to the NB's result anyway during the day, but it's not sure that we would have a common understanding about it. One would think that the team is a little bit bellow the burndown guideline so it's OK, so he/she can spend more time on fine-tuning some insignificant little feaute but other would have some knowledge that the team will meet serious problems soon. There might be discussion about it during the day even in person or in team-chat but some people might miss it who are working on some task very deep. If there's too much discussion that's too much noise which prevents concentration to the real work.

Then a round happens when everybody tells what he/she did the day before and what will do on the current day. Others don't just listen and look out on the window but also think in themelves if they are affected by the current person's status update. Short, some second interruptions are permitted.

'What did you do yesterday?' It's just for making a context for today's plan but also gives some useful information. If the progress of the sprint isn't good enough we are usually more critical about this question. 'You couldn't do the anticipated progress. What was the problem, was it solved or do you need help?' It's important that's not about blaming.
Without standup: We'd eventually discuss what were we doing recently and if we have problems but more introvert people would tend to keep their problems inside for a longer time. This could cause quite some delay and loss of effectiveness.

'What do you do today?' We discuss this by looking at the task board. We make sure that everybody has some task, optionally who is blocked by what. Usually the outcome of this round, by some interruptions, that some people want to have some short discussion after the standup about how to continue the work, how to collaborate more effectively for the subsequent tasks.
Without standup: eventual discussions would happen during the day but as before, it'd cause too much noise and/or some people might miss important pieces of information.

At the end of the standup we set up a realistic goal for the day which everybody agrees with: 'We should close this story today.' 'We should finish this and that tasks for the story today.' This makes some motivation and makes some common standpoint again. This can be the base of the next day's standup but also It's very good when at the end of the day some well definiable part of the story is done.
Without standup: we could set up a goal during random discussions but it's quite not lifelike. It's much more likely that everybody would work with a regular, or little bit less, motivation and the story would proceed as it comes. Probably more half-baked and non-integrated parts would remain for the next day which isn't so lucky.

So, I think a standup, or any daily dedicated time-slot when everybody is listen responsibly and responsively, call it what you want, is quite useful and makes a team more effective and motivated.

Of course it's not straightforward that every team who does standups will become suddenly effective. There are some agile antipatterns which can make standups or using the whole agile methodology useless or meaningless, but it's another story.

5/6/14

Architecture at CraftConf



At Craft Conf, there were some presentations about software architecture. I visited all of them and also searched for this subject in other talks. It was interesting to hear the same concepts from more places and to put together a picture how software architecture looks like in the mind of the presenters of today’s conferences.

Stefan Tilkov: Architecture War Stories. It was indeed about weird stories from real life. I wrote down two things: If something is sophisticated, probable you shouldn’t do it. And having many architects is wrong. Many people liked this talk very much but I’m not really interested in real stories. I’m rather interested in the causes behind the stories to be able to avoid situations which head to weird architecture. Luckily for me, other talks were more abstract.

The title of Rachel Laycock’s talk contained the very fashionable word combination “Continuous Delivery” beside “Architecture” so I anticipated it will be great, and it was. Rachel came with the same mindset what I heard two years ago at Devoxx from Kirk Knoernschild. She used the phrase: Architecture is the stuff which hard to change. Architecture isn’t how the big parts fit together as some older sources say. She listed the five most important principles:
  • Last responsible moment. - defer decisions if possible. (Managers demand a stake in the ground approach because it’s more comfortable for them but it’s in violation with modern architecture principles like ‘last responsible moment, defer decisions’.) 
  • Architect for evolvability - don’t try to fix everything. 
  • Postel’s Law, a.k.a the robustness principle: - Be conservative in what you do, be liberal in what you accept from others. In other words, code that sends commands or data to other machines (or to other programs on the same machine) should conform completely to the specifications, but code that receives input should accept non-conformant input as long as the meaning is clear. 
  • Architect for testability - (good design is testable) 
  • Conway’s Law. - The Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”. Another thought about Conway’s law from Fred Brooks (mythical man-month): “Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organisation is important to effective design.” 
She mentioned microservice architecture as a good direction (not the only one who mentioned it) and explicitly suggested not to use ESB or at least not to put any business logic in it. There were three recommended readings (all from Martin Fowler): The Strangler Pattern, Branch by Abstraction - these are articles and a book: Continuous Delivery. Well, not too many words were spoken about Continuous Delivery.

I’ve heard an important aspects about Continuous Delivery at other talk: Don’t use branching but use flexible runtime feature flags.

Title of Simon Brown’s talk operated with the other fashionable word “Agile”. I didn’t like this talk as much as Rachel’s one, maybe because I didn’t hear what I wanted. Simon said, that one architect should be enough in a company, or at least very few. It was said by Stefan Tilkov also, but in other articles I saw opinions about being all developers some kind of architect is the good way. I think the truth might be somewhere between. The other thing which I didn’t like the need for a proper UML diagram of the system, although, sometimes I also print a diagram for myself of the currently developed software, but it’s not necessarily standard UML and far not proper. It’s not maintained together with the code. He mentioned C4 which is also in connection with diagrams. In his definition: Architecture is the significant structure elements or architecture is the structure down until component level. Further advices were: Just enough upfront design is enough, never do Big Upfront Design. He recommended this book. I liked he mentioned that there’s something between monolithic and the very fashionable microservice architecture, it’s impossible to make it in one go, it can be implemented by a continuous transition.

In Nat and Steve’s presentation’s title there were no Architecture just SOLID. I liked very much the different kinds of pasta they showed for us, especially because we were before lunch. So, basically there is the spaghetti code which we know all, it’s the good old procedural legacy code. But OO code is all nice and clean? Well, maybe not. There is lasagne code, which is OO but it’s just layers on top of each other and you never get to the bottom. Ravioli code is also OO but you can’t get how and why the different objects and classes piled up on each other, possibly by the dependency injection framework. And there is OO spaghetti code which is made by events and event handlers and it’s similarly hard to unravel it’s behaviour like the procedural code (if not harder).

Michael Feather’s talk’s title was very specific because it contained the “Conway's Law”. He recommended to read the Leaky Abstractions from Joel. Mentioned Feature vs. Component teams. In some corporation teams may work on features or components and it’s reflected in the software itself. Further terms or recommended practices were: oscillating teams, production coverage, silent alarms, ownership.

Other very popular subjects of the conference was Continuous Delivery and Functional Programming which both have some connection with architecture. Though reactive programming and functional idioms very low-level stuff, not how the big parts fit together and not component-level design, they play an important part in architecture. So yes, I could cite some other talks where architecture was concerned but it’s time to stop here. I learnt a lot, everybody should learn a lot about it, and it’s not the last post from me about this subject.

And don’t forget, that quality means many different things, but customers are interested in functionality.

4/29/14

Craft Conf Workshop - Gojko Adzic

The day started with a mistake I’ve made. I didn’t check my mailbox accurately and missed the info that workshops aren’t held at the conference venue. I knew that there were some email but I thought it’s redundant and everything is on the homepage. It wasn’t. After all, I managed to track it down and get to the Prezi office in time when the workshop was held.

The workshop was about  How to Make Big Impact with Software Products and Projects by Gojko Adzic. We had to form group which was very nice because most people didn’t know each other. We had to come up with an imaginary milestone plan for some kind of a software. It was interesting that the seven groups came up with quite different ideas and every group was able to defend his own viewpoint. One group defended the idea that they didn’t want to touch the legacy code of the system, other team came up with the idea to rewrite the legacy part. The conclusion was, that no ranking can be defined, it’s nearly impossible to judge, which will be the best solution. It was also extremely difficult to work with people who I didn’t know and not necessarily agree with them, but we have to came up with a solution in five minutes.

In other tasks we had to make mindmaps and implementation plans and after each task the presenter held a presentation about the conclusions of our results. Some takeaways:
  • Make a victory condition for user stories, which is different than DoD which is a technical thing. Victory is, when the story really works in the practice as it was expected.
  • A user story should be about changing a behaviour not creating one. In most cases the operation, which is described by the story, is already doable but maybe not enough effective.
  • Raise the level of discussion. Challenge stories, they’re not given by god. In fact, users aren’t designers, they can’t design a software. Never rely blindly on their claims.
  • Never say No to stakeholders just Now or Not Now.
  • A story can be sliced in many different ways, for example by a group of users.
  • Quality means many different things. It’s hard to come up with some success criteria but in most cases more aspects have to be investigated. If a high-quality code doesn’t fulfill the users’ functional requirements it’s still valueless.
  • Reserve a learning budget. Implementing an easier variant of the functionality may give useful feedback about the correctness of the idea. Implementing doesn’t necessarily means writing code. An automatic behaviour can be mimicked by hand for some users (for example sending ‘automatic’ notifications).
  • A Maslow pyramid can be defined for software, where the lowest level is the fact, that the software actually builds and runs. Next level up is to be performant and secure, then to be usable, then to be useful and the top is to be successful.

So, the message was basically injecting the lean process into the Scrum/Agile process which I very much like. I don’t think if all companies can apply this, especially the ones which still have some waterfall-ish way of thinking but it’s definitely a good direction for startup-like companies.

The presenter had another talk on the conference with somewhat similar content which can be seen here.

It was nice to form groups and the workshop itself was great. On further days of the conference I met some former team-mates and had some discussion with them. It was also interesting to see Prezi office basement and their magic words (boarding, prezilians, HP). We had a great dinner in Apacuka. After the workshop I had a glass of wine in Aquarium and one more near Epam office, then I went to one of the meetups but let it be the subject of another post.

10/10/13

Some useful Java libraries

Here is a video from Javazone, where some useful Java libraries are mentioned:

02:30 xbean-finder: Annotation finder in jars.
03:50 shrinkwrap: Can download artifacts from Maven repo.
05:50 zt-zip: zip file utils from Zeroturnaround.
07:25 Airline: command line parser helper.
10:30 really-executable-jars-maven-plugin: makes self-extracting jars.
12:00 jansi: colorized command line.
13:30 jmxutils: JMX beans by annotations.
15:00 Feign: HTTP helper / annotation lib. OkHttp is also mentioned.
17:20 Jerry / Lagarto: JQuery-style selectors in Java.
20:00 jchronic: converting English free-text to time.
21:40 assertj: fluent interface for asserts in unit tests.
23:10 vtte: very trivial template engine.
24:45 tape: a collection of queue-related classes for Android.
26:10 connector/mxj (GPL): mysql helper.
28:10 ness-pg-embedded: prostgresql helper.
29:10 slice: effective off-heap memory helper tool instead of ByteBuffers.
32:20 paranamer: named params in java from bytecode.
34:00 sshj: ssh client.
35:00 sshd-core: ssh daemon.
36:50 jline2: emacs style CLI helper.
38:00 zt-exec: starting processes conveniently.
39:30 jBcrypt: password hashing easily.
40:50 joda-money: helper for working with amounts of money.
42:10 jnr-ffi: JNI helper.
43:30 sqlite-jdbc: jdbc driver for sqlite.
44:50 java-classmate: generics parameter type discoverer.
46:20 jackson-module-afterburner: speeds up Jackson.
47:30 jackson-dataformat-yaml: YAML support for Jackson.
48:20 unix4j: command line tools from Java, like grep.
49:40 parboiled: parser generator library.
51:45 MVEL: simple brebuilt expression language.
52:40 typesafe-config: tool for reading configs.

8/30/13

SAX Parser truncation problems

Have you ever met with strange problems regarding SAX parser when textual content seems to be truncated? When it seems that the parser transmits only a fragment of the content which is inside an XML element. Maybe not. Maybe yes but haven't noticed.

Parser reads blocks of stream and it may call characters method more than one times. Well, it's written in the Javadoc and it's quite logical. If I have a very long text content, it couldn't had been processed in one go. It has to be split into parts.

So, rather than assigning the content to a simple string, use concatenation instead and evaluate the content on endElement.

By the way, the magical number is 2048. The parser implementation typically uses this block size. Unfortunately it's a kind of thing which easily creeps under the radar of tests. Nobody writes tests for long data.

See also this on Stackoverflow.

5/9/13

NoClassDefFoundError

Recently I faced with NoClassDefFoundErrors during unit testing despite all class files were in place. It was quite strange. Furthermore this error happened only on our CI (Linux) server, I couldn't reproduce it on desktop, neither on Windows nor on Linux.

I started to investigate the stack traces and it seemed that the native open method of the FileInputStream was failed. After more investigation by JProfiler I found, that many classLoader.getResourceAsStream invocation happens in our code, but those streams are never closed.

Meanwhile I found this nice writing about Tuning Linux applications which says: "Some Linux applications; for example, a JVM, might require a higher file descriptor limit. If an application can't open files because the file descriptor limit has been exceeded, you might get a NoClassDefFoundError error message."

Then it says how to increase number of file handlers (ulimit -n 2048), but let's rather close the resources guys. It would have been quite unlucky if the application starts saying NoClassDefFoundErrors in the wild after some days.

9/22/10

Installing Firefox Java plugin on Ubuntu Linux for Dummies

As a Windows user, I was amused how not easy to install Java on Ubuntu Linux (10.04) nor installing Java (1.6) plugin into Firefox (3.6). It's not nearly a download-next-next-finish task. Additionally, digging into forums I found a lot outdated solutions which I tried and soon realized that they doubtlessly aren't working. Here is the one which worked for me:

First, open a terminal window:

Applications menu -> Accessories -> Terminal.

Type the followings (you will be promted for admin password, because sudo prefix means you want to do something in the name of the super (or sytem) user):

sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
sudo aptitude update
sudo aptitude install sun-java6-jdk

Then you have to select things with arrows and pressing enter.
Then Timothy says in the forum you have to type this, but I didn't need it:

sudo update-alternatives --config java

Now you can check if java is installed by typing java -version.

Installing Java plugin into Firefox is no more than making a symbolic link with the ln command. I had to go in the /usr/lib/mozilla/plugins directory, then make the symbolic link with this:

sudo ln -s /usr/lib/jvm/java-6-sun/jre/lib/i386/libnpjp2.so

Restart Firefox if it's running. Java may work.
Sorry for the laxity, I'm still a beginner Ubuntu user.