Sunday, October 26, 2014

Afterthoughts - Tampere Goes Agile '14

What would a year be without Tampere Goes Agile? To paraphrase this years motto "we're all in this together". This was visible in talks throughout the day.

Compared to the last year the event was a bit smaller (~135 vs. ~ 235 people). Despite this the event had some very high quality content some of which I'll highlight next. Perhaps the most interesting thing about this year was the inclusion of multiple workshops in middle of the day.

Considering Tampere Goes Agile is a free event for participants the quality of it keeps surprising me year after year. Besides excellent selection of talks you get to meet a bunch of great people.

Woody Zuill - Mob Programming

The day started with a keynote by Woody Zuill. Initially I was a little skeptical. How could you possibly develop software in a mob? Apparently quite well!

Traditional Split

Traditionally software development has relied on division of labor and expert work. The problem is that once you start to split work you will end up with all sorts of dependencies. This in turn can lead to development blocks and wasted time as you are forced to wait or just do something else while at it. 

Multitasking just makes the situation worse. You will end up jumping between tasks while waiting for answers. This in turn creates stress that definitely doesn't help.

Get Together?

What if all the people that have the answers would be in the same room at the same time and developed the software together? You could invite domain specialists or the client even to participate in your sessions. Even though this might sound a little strange approach it alleviates those concerns I just highlighted.

When you are working as a mob this allows you to focus all the energy on a single task at a time (automatic single piece flow!). If you end up blocked there is someone with the answer in the vicinity. It is like the concept of pair programming scaled to the team level.

Woody's Approach

In Woody's configuration there is a single driver (rotated every 15 mins or so). That person writes the code. The rest operate as navigators and guide the driver. The primary advantage of this seems to be that while the driver can think in code the rest can focus on thinking in human terms. They might also spot inefficiencies and help guide the driver towards better technical solutions that might not have been found otherwise.

Given there is so much expertise in the room at the same time this might allow the team to avoid entire categories of problems or eliminate some of the existing ones! Multiple perspectives seem to allow this and the approach helps to avoid some of the traditional sources of waste in software.

The approach isn't without its challenges. It could prove challenging for certain people as it literally brings your work out in the open. Working directly with other people isn't the way software is normally developed. For work like this to succeed you will need to remember to be kind, considerate and respect others even if they might be wrong or irk you in some way.

Besides removing waste the approach allows information to be shared more effectively (reduced bus factor). As it encourages information sharing through collaboration people pick up new skills faster. This is something you simply don't get in a segregated environment prevalent in the industry.

Takeaways

Mob programming is something Woody and his peers discovered through introspection. It was not just something that came out of thin air. Rather they ended up developing software this way because it felt like the right and most effective thing to do. To quote Woody you should find your own way. That said, maybe mobbing works out for you but don't expect it to be a silver bullet.

Per Jansson has written an introduction to mob programming that might give a better idea of what it's about.

Making Work Flow - Lauri Hahne

The gist of Lauri's talk was in how do traditional approaches fail us. He sees software development as a systems and a learning problem. This is very opposite to the waterfall view. I agree with Lauri here. The system, context in which we develop software, puts heavy constraints on productivity. Unless you are developing something you have done before exactly, learning will need to happen. Both of these contribute heavily to project success even if you aren't aware of the issue.

The Traditional Model

The traditional development model is very static in sense that it builds on things like requirements management, HR and distribution of work for maximum utilization. The traditional model focuses heavily on aspects such as technology choices, finding proficient people and division of labor. Teams are formed per project, work is performed on individual level and all of that is managed by a project manager.

If you are building something you have developed before I have no doubt the traditional model couldn't work. What happens, though, when you need to work on something more complex? How do you know you are building the right thing in the first place? How do you measure the impact of your results?

The traditional development model has a lot to owe to Taylor and the industrial era. The theories expect that people are lazy by default and need to be managed for work to get done. Specialization is required to get most out of division of labor. What if some, or all, of the assumptions we've built our development processes are wrong?

What Are Good Teams Like?

What if people aren't lazy and actually want to get things done? What if good teams are larger than the sum of their parts? What if it is beneficial for people to have cross-competencies, not just specialities?

According to Hahne teams that finish early, accelerate faster. He highlighted the importance of stable teams, swarming (single piece flow again!) and scrumming the scrum. You have to be prepared to work on the way you work for things to improve.

You will likely have to discard some of the older ideas to get better. There are plenty of sources for new ones. Of these Hahne mentioned Toyota Production System (Kanban etc. come from here) and John Boyd's Blitzkrieg. He also suggested rethinking division of work. What if you operated per technological layer, screen or feature as a team. It's not a huge leap to mob programming from here.

Hahne values stable teams of teams formed per project. Stable teams operate more consistently, eliminate HR and allows them to operate more effectively as you minimize the effect of Tuckman cycle related to forming of teams.

Hahne highlighted swarming as it will allow each team to operate on a single task at a time (single piece flow). Rather than working on tons of smaller issues at once you actually focus on getting something ready. This eliminates a significant amount of waste and multitasking which in turn improves productivity.

Focus on Process Improvement

Hahne's focus on working on the process itself was prevalent. You should have a good idea of what is blocking team's performance and take steps towards eliminating it. Again, focus on teams seems to be the key here.

If software development has taught me anything, it's that errors pile up and accomplishments disappear. When things go south, people start feeling bad and the cycle gets even worse. If you rush things to make a deadline, you will pay for it later in forms of technical debt and reduced morale. What if you could do things better in the first place and avoid this?

Takeaways

Traditional software development puts too much emphasis on artefacts that have been derived from the industrial era. What might have worked for some tycoon a hundred years ago doesn't quite do the trick in modern, dynamic world.

I agree with Hahne in that teams are a suitable smallest unit. Split work per teams and don't split up teams. Pick new concepts as needed and remove those things that block team success. It is not like you can build a superb team over night. It might form over a longer time, though. Invest in your diamonds.

Trying to Change Company Culture is a Fool's Errand - Sami Honkonen

I have discussed company culture earlier. Sami's talk gave good food for thought. How are cultures formed? How can you change cultures? According to Sami in order to change a culture, you will have to adjust system conditions that cause it. In short culture should be seen as a result of all the things that are going on, not something you can tweak directly.

Context is the King

If you want to change a culture, you will have to adjust the context. If your cake (culture) tastes bad, you will have to bake it differently using possibly different ingredients. Maybe your cake (culture) will be better that way.

How do you know what to tweak then? It turns out system conditions are everywhere. Sami gave a fish tank as an example. Just to give you some idea, at least the following conditions affect the system: lighting, oxygen level, amount of fishes, race of fishes, amount of space in the tank, cleanliness, nourishment, decorations and so on. You can think up a lot more.

How to Change Company Culture?

It is possible to come up with a similar list affecting a company culture. In order to change the culture you will have to change these factors. As an example let's say your company is one of those cubicle farms. How do you think it will affect the culture? The work is likely done in isolation and the people rely on email a lot. The culture is focused on individual performance. This in turn prevents working with others. If you wanted to change this culture, you would have to change cubicles into something else.

Another example is limited WIP (work in progress). If you have the system set up based on teams as Hahne suggested and enforce a WIP limit of one, it gives the teams a very high incentive to focus on finishing. If you take this further and provide incentives based on team performance, you will find that it will be difficult for teams to collaborate with each other.

Takeaways

Sami's talk described well what culture is about. It's something that exists as a result based on system conditions. If you change these conditions, the culture will change as well. There is no direct way to modify it. Rather you tweak it indirectly like this. Even small things might have surprising effects and I expect it's a whole can of worms if you really start thinking about it.

In short if culture eats strategy for breakfast, system eats culture for lunch.

Introduction to Retrospective Facilitation - Ville Ruuskanen

Isn't nostalgy great? Who doesn't love 80s clothing and music? Thankfully retrospectives don't have to go that far and you don't have to wear those tight 80s clothes to facilitate them.

Why to go Retro?

The primary advantage of running retrospectives for your team is that they provide a great chance to perform introspection and think about what works and what doesn't. This ties back to Woody's and Lauri's talks in which they highlighted the importance of process improvement. You shouldn't run a retro only at the end of the project. Rather the greatest benefits are gained if you measure the pulse of your team continuously. In Ville's case he seemed to prefer a longer one (2-3 hours) once every two weeks though your mileage may vary.

There is no single right method to run a retrospective. Instead you should thrive to vary their content. Ville provided a rough frame in which you can build the event itself. I won't go through the details as you can find them in the slides below.



Given there was another workshop running in the same space at the same time, it was a little noisy at times. Apart from that it was just great as I didn't know much of the topic beforehand. If I ever have to manage or lead a team, I will have yet another nice tool at my arsenal.

Self-Management, practical tips for your personal journey - Erik Anderson

In order to remain competitive in the current business environment, you will have to continuously push yourself forward. This was the topic of Erik Anderson's talk. Curiously self management is one of those topics they don't teach you at school. Rather you are expected to pick it up yourself and some people just fail to do that. If you are aware of the issue, you can probably do something about it.

Erik split the topic in three overlapping parts: body, brain and society. We can do something for each up to a limit. Especially the society part tied back to earlier talks. Where and how you work affects your well-being directly whether you acknowledge that or not.

Body

It is important to keep in mind that humans used to roam savannah. Modern life as is is quite recent invention and we certainly haven't adapted to it perfectly. This in turn causes all sorts of problems for bodies designed for something else.

If we keep these constraints in mind, we can understand better why exercise is so important yet undervalued. Being in a good physical condition affects everything. In addition effects of sleep and proper diet should be kept in mind.

Brain

Interestingly exercise gives your brain what it needs in order to change (improved learning, memory). It is possible to "hack" brains in various ways. Sadly they don't provide user's manual with them. I guess we wouldn't be so lost otherwise.

Mindfulness, being aware of what you feel, allows you to observe what you feel rather than react. If you train the brain through meditation, it will get stronger just the way body does when you learn it.

It pays off to understand how habits work and what happiness means from perspective of brains. Learned helplessness/optimism is another of those concepts people should be aware of.

It is easy to end up in a cycle of depression because depression causes more depression. Breaking the cycle is the problem. On the other hand it might be possible to gain optimist traits and get into another kind of cycle. In the end it comes down how you deal with adversities in life and react to those.

Society

Erik discussed topics of personality styles, personal strengths and team profiling. I know personality tests and such sound like pigeonholing but the fact is that each of us has their preferred way of working. It is important to be aware of that as that is something that contributes to our happiness.

If you can adjust the way you work to suit your personality better, you will likely achieve better results and be happier while at it.

The way we relate with society has a big effect on us. Erik described the concept of transactional analysis. The key thing to understand here is that a person is a multi-faceted concept in how it relates with the world. These facets (parent, adult, child) get triggered in social situations and helps to explain why responses are the way they are. If someone snaps at you, maybe there was something about the way you poked the person that triggered the child response to parent question?

Takeaways

Erik's talk showed that there is a lot to learn about. Self management and improvement are large topics. To quote Erik you will have to keep on tweaking things to see if they get better and be open for changes. That is the way forward.

Conclusion

It's probably not an understatement to say that this Tampere Goes Agile was the best one so far. I loved the talks and even the party after the event was fine although I felt embarrathed over wordings of certain agile songs performed. I hope the event will be arranged again next year and definitely plan to go it if is!

Monday, August 4, 2014

A Quick Look at Modern Text Editors for Web Development

Even though there have been text editors for a very long time it seems there is still room for innovation. You might think that perhaps Vim, Emacs, is enough. Regardless new alternatives seem to be popping up. In this post I'll take a brief glance at a few to give you some idea of what's going on in the field.

Editors

Some OS X users might still remember TextMate (now open source). You could say Sublime Text pretty much replaced it. I tend to use both Vim and SublimeText with Vim bindings these days. There are a few interesting alternatives around the corner, though. Particularly Light Table, Adobe Brackets and GitHub Atom have gained publicity and I'll take a better look at those.

Light Table

Light Table is perhaps one of the most hyped new editors out there. It provides an interactive programming environment. You can execute your code within the editor, modify and inspect it as it runs. You can see the concept in action in the video below.

Besides being suitable for interactive work it is possible to extend and customize Light Table somewhat as seems to be true for the newest generation of editors.




Adobe Brackets

Inline editing in Brackets
Brackets is an editor specifically designed for web development. Rather than just being a fancy text editor it provides an integrated approach for web developers.

For instance instead of having to modify HTML and CSS files separately it allows you to open CSS related to given HTML tag within the view itself.

It also provides live editing as a built-in feature. This way the changes you make are visible in the browser instantly without having to refresh it explicitly. Currently this works with Chrome only.

There are also advanced debugging capabilities that are not available in regular editors.

The video below illustrates the basic ideas well.



GitHub Atom

Just like Brackets, GitHub's Atom is built on web technologies itself. It comes with a package manager built-in and is easy to extend. You could say it has been very inspired by Sublime Text and it is likely easy to adopt if you use ST already. In addition there's Node.js integration available. That's another handy feature for plugin authors.

It's probably not an earth shattering editor yet but given its modularity and backing it would not surprise me if it became very popular within a year or two as it develops.

Again, check out a video to understand some of the basic ideas behind the editor.



Other Editors

Besides the editors discussed above there are entire IDEs to check out. WebStorm is definitely worth checking out if you are into that sort of thing. Angular support in particular might be of interest for some.

Dart programming language comes with an environment of its own. Dart editor benefits from optional typing supported by the language and makes it easier to catch certain category of errors earlier than in vanilla JavaScript without a runtime hit.

Besides "traditional" editors there's a whole category of a web based ones. Cloud9 and Codebox provide good examples of these. These type of tools allow collaboration (ie. pair coding and such) in a way that might be difficult or impossible to achieve using some other editors.

Lighter web based editors such as JSbin, jsFiddle or jsdo.it have their place as well. They might not have as strong collaboration features (ie. realtime) but are often enough for illustrating a specific problem or implementing small demos.

Conclusion

Overall it seems editors are specializing and provide more support for interactive editing than before. Older editors will still retain a following. Newer alternatives might be easier to modify and some even provide special functionality that has been developed particularly web developers in mind.

For now I'll stick with my Vim/Sublime combo and keep an eye on the newcomers. Transition from Sublime to Atom should be straightforward for instance. As long as there's support GitGutter (git diff in gutter), EditorConfig (enforces coding style), formatting and interactive linting I should be a happy camper.

Live editing, as provided by Brackets, can be provided externally. These days I prefer to use BrowserSync and invoke it through a Gulp based build. Broccoli might be a good alternative longer term but I'm waiting for it to mature for now.

The next step, bi-directional editing, is mostly handled with Tincr. Of course editing pre-processed files (SASS, LESS, ...) remains a problem but you can't get it all, at least yet.

Thursday, July 3, 2014

How I Learned to Stop Worrying and Love React

You could say JavaScript frontend development advances at a rapid pace. Every few months new technologies are introduced. One of the perhaps most interesting recent ones is React.js. It is a library developed by Facebook that focuses on rendering views.

Most importantly it bridges the gap between frontend and backend. It is possible to render the markup on backend and have frontend pick it up seamlessly. It is blazing fast thanks to its DOM diffing algorithm. It is so performant that even Atom, an editor developed by GitHub, is moving to use it.

I see solutions such as React as a natural next step. Backbone, Angular, Ember and such will still have their place. You can even mix React with existing technology to enjoy some of the benefits.

Web Components can be seen as a competing approach. polymer.js, a project established by Google developers, would be the library check if you want to learn more. Maybe Web Components are the way of the future.

Getting Started with React

Time to react by
Ian Nolan(CC BY-SA)
There is not that much to learn in React. It is more about understanding some basic concepts. When coding in React you'll split up your view into smaller components that may contain others. They can contain some internal state and properties which may be passed to the component to render. You can also deal with events at these components and then manipulate the state.

The fastest way to understand the way it works is to check out the official Fiddle and then try out some tricks available in the documentation. The Fiddle I linked to relies on something known as JSX. It is an XML like syntax designed to make it easier to write templates. There are tools available that can render it to regular JS. You can also write the JS directly although it's more cumbersome.

The biggest gotcha with using JSX is that it gets more difficult to use tools like jshint since they won't recognize the custom syntax. EDIT: It is possible to use a wrapper such as jsxhint to lint JSX code. (Thanks Esa-Matti.)

Invoicing Demo - Combining React with JSON Schema

I wrote a small invoicing application as my first React exercise. Try filling some fields. You can get an invoice simply by printing out a pdf.

Technically it is somewhat simple. Initially I wanted to use Angular and some form library that supports JSON Schema well. The idea was to generate a form based on schema and then use that to control model that is tied with the preview you can see at the demo. Unfortunately I was unable to find a library that supported nested properties (ie. objects inside array).

As I didn't feel like hacking some existing library and React has been on my list of technologies to learn and adopt for a while, I started looking into a JSON Schema based library. I managed to find one in form of plexus-form. After fiddling with their demo for a while I realized I should go with it. Even though it wasn't aesthetically most pleasing the core worked very well. After some iteration with the author the library we made it fit my purposes perfectly.

Besides React and plexus-form I adopted Gulp in this project. It is a streaming build tool that avoids some of the complexity of Grunt. Apparently it is faster and best of all given all the configuration is in code it's easy to maintain and develop using it.

The final bit of new tooling I adopted was Tincr. It is a Chrome plugin that allows bidirectional editing of CSS. I like to fiddle with CSS in Chrome Inspector and then move the changes to actual CSS. This plugin allows me to skip that latter part and makes it much faster to do tweaks.

If you study invoicing app source, you'll notice I've split it up within components and a form schema. The components are fairly self-contained. I could for instance reuse Form pretty much as is in some other project. I also love the fact that if I want to add a new field and hook it up with the preview, I need to modify just the schema and preview template.

You can also see that I used something know as LocalStorageMixin in my form. Adding that little line of code there allowed me to persist the component data within localStorage so it's available when you reload the page. How neat is that?

The build is based on browserify and various other tools (BrowserSync, reactify etc.). Browserify allows you to use the same module scheme you have gotten used with Node.js. This workflow also enables server side rendering with minimal effort as an example by mhart illustrates!

Weather Demo - Combining React with FRP

Even though React works great as is dealing with events could get hairy. Functional Reactive Programming (FRP) provides a solution for this problem. It allows you to control events on the level of streams. You can modify these streams for your purposes and then pipe them to your components. As it happens React and bacon.js, a FRP library, fit very well together.

To make things easier there is a BaconMixin that provides the sort of functionality that makes this type of work simple. I still don't understand every details of it but to get started I forked the original GitHub based example of the library. I modified it to fetch weather information from OpenWeatherMap API. It is not very aesthetic in its current form but it was more about piping.

As FRP is still quite a new topic and not that well understood I recommend checking out André Staltz's excellent introduction. It is one of those abstractions that might change frontend development as we know it.

Conclusion

You could say I have been quite impressed by React so far. It simplifies development a lot. Having stellar performance doesn't hurt. Compared to something like Angular there is far less to learn. Of course it's a different beast. Apples and oranges.

To scale up from just doing cool little things with views, you could look into rrouter, a routing library, and Fluxxor. Latter provides tools that allow you to implement something known as Flux architecture.

If you need to implement small interactive views I would say React can be a very good fit. There are some gotchas of course (ie. dealing with Bootstrap plugins) but overall the experience has been very positive.

Monday, June 30, 2014

Linkdump 22 - Business, Software Development, Programming...

Time for a Summer dump! See also previous one.

Business


Software Development


Programming


Web Development


Hardware


UX


Art

Wednesday, June 11, 2014

Projects Are the Antithesis of Projection

It is a well known fact that software projects fail more often than not in some way (ie. Chaos Report). Either deadlines are missed, objectives are not reached, budget goes beyond allotted, you name it. If you are a software developer, you have likely blown up a project at least in one of these ways.

Essentially a project is a control mechanism. By definition it is something performed by a temporary organization that should reach the project goal. Once the goal is reached, the project is done and closure is reached. The organization may disband and move onto other projects.

What if there was some other way? Who says software has to be developed within projects always?

Projects Are the Antithesis of Projection

Compass by The B's (CC BY-NC)
Projects might work for one-off thing that you can implement and forget. This is missing one key point, however, software evolution. A project might reach its goals on time and on budget but what about the future? The way I see it projects are an antithesis to this kind of projection. They encourage to focus on short term while forget about long term.

That said maintainability concerns can be taken in count during project. It is just that by definition they don't encourage to take the long term view. As projects are performed by temporary organizations there might not be commitment to reach for the best long term result either. And what is the best long term result even? What looks good for the project/product owner might not look good for contractor.

The tried and true engineer's triangle applies here. You always have to make a compromise between good, fast and cheap. It simply isn't possible to get everything at once.

Alternative Control Structures?

Control structures by Martin Fisch
(CC BY-SA)
Given projects are about control can we organize development using some other structure? Projects by definition lead to side taking. There must be some product owner and the people that actually implement the project (ie. contractor). The goals of these two parties are often different and can lead to conflict.

Let's say we build a project based on a fixed set of requirements, fix the cost and schedule. After that it's up to the contractor to implement the project within those constraints. The problem is what if the requirements change during the project? If the cost and schedule are fixed and the product owner is not willing to compromise, this could lead to serious issues. Something has to give in.

What if instead of pushing and fixing we did something different? The product owner likely has a good idea of the product goals. An alternative control structure could be developed based on those. Rather than fixing everything upfront and then trying to find the cheapest company to do the work, something else could be tried. How can you achieve this without taking sides so clearly?

What if you tie the destiny of the product owner to the destiny of the contractor somehow? Instead of aiming for something as cheap as possible to maximize short term gains you would think long term. One possible solution is to treat the contractor as a business partner. In product development this might mean something such as profit sharing.

You could also build something on weekly basis (ie. charge per week against results). Make the arrangement so that either party may fire the other after each week. If either party is disappointed for some reason and wants to move on, let it happen. This forces both parties to focus on building trust if they want to keep it going on.

There are still sides but at least they are aligned better than in traditional projects. There is a clear continuum and it is in the best interests of both parties to maximize their efforts to gain trust. That is essential for maintaining a long term relationship and minimizes some of the risks. Now that you can think forward even projection becomes possible and you can think about future.

Conclusion

I think it is very interesting to follow the current #NoProjects discussion. It feels like we might be onto something here. I am not saying projects could not work in some contexts. More often than not it feels like a construct that has been developed to maximize the wrong things. It's hard to project with projects.

This post was inspired by Allan Kelly's post on the topic. Also the comments on the blog were very insightful so I recommend checking that out if this sounds interesting!

Tuesday, May 20, 2014

Linkdump 21 - Business, Software Development, Programming...

Dump time! Also see the previous one if you haven't already.

Business


Software Development


Programming


Web Development