Reaching the Next Level

When a new programmer starts writing code, s/he requires detailed specifications and clear requirements. The understanding is on a level "I need to get this piece of code working". There's not very much thought given on what happens outside this routine or how things are connected.

On the next level, the coder understands that the piece of code s/he's writing is a piece of a larger system. This system exists for some purpose, but the purpose isn't necessarily clear for the person. But generally s/he understands the system is important for the company and probably generates financial benefits (i.e. is sold).

Reaching the next level is already quite challenging. At this point the developer starts to think about the customers' business. How do the customers make their money? (...that can be then invested. Maybe in software. Maybe even on the solution you are developing...) And when you understand how the customers make money, you understand their priorities and needs. What is important for them and critical for their business.

There might be intermediate levels between the ones I mentioned, but I think this covers the basic steps. I'd encourage all developers to try to advance on these steps. The higher you are, the better you can fill your customers' needs and thus the more valuable you become. I'm not saying that code writing is easy. I'm simply saying that being able to write code AND understand the business is a tad harder and rare. Development on this path starts from understanding the user. 

(Sometimes the decision maker for software purchase is not the same as the user. Users might be only influencers in a complex network. But let's leave this out of scope for now. )

Software Development - More Than Coding

Think about software development. I'm assuming you have an image of someone writing code in your mind. Well software development is that, also. But it's also much, much more.

In my company I'm responsible for the software development in this more broader sense. When I think about software development, everything begins from the customers. Developing software is solving customers' problems. Selecting what problems to tackle as a company is a strategic choice. Strategy narrows down what you develop and helps the company focus. Probably it also states in which markets you want to compete in.

Strategy helps the company define it's portfolio. What customer problems we want to solve and what kind of solutions we offer? The solutions can be products or services. Strategy should guide you in this. If it doesn't, refine the strategy.

Let's now assume that in your offering/portfolio you have product(s). Each product should have a vision. What the product will be in the future? What customer problems will it solve when it will be in it's ultimate, final form. (This form will never see the daylight. Vision serves as a distant goal, something to strive for. It's an idealisation that will be even more magnificent when you get closer.)

Vision will help you define a roadmap. Where as vision can be hazy, the roadmap should be really concrete and tangible. I think of roadmap as a guidebook for the next steps toward the vision. If your strategy is planned for the next 5-10 years, roadmap could cover maybe 3 years. It's worth noting that it's still a high level plan and as for any agile plan, subject to changes.

In software development roadmap is implemented in releases of new software versions. They are usually developed in iterative and incremental fashion. Old functionality is modified and improved with new features and bugs and defects are fixed. Many times companies try to shorten their release cycle. The ultimate case would be Continuous Deployment where every change would be deployed to customers. But this is very much industry specific. In some cases the overhead of taking new software version into use is so big that customers don't want to do that often. Then it's practical to select a release cycle that suits both the company and the customers.

In agile development, software is usually created by small teams in an iterative fashion. The length of these iterations or sprints is usually limited to less than a month, a little bit depending on the selected methodology. Sprints are like mini-projects; they are planned, executed and in the end there are sessions for examining the results and for learning from the experience. ...and then cycle starts over again.

Daily work in sprints is carried out by the development team. Developers are experts in their field and select the most fitting methods for the implementation. They have the authority for carrying out daily decisions.

We got to the part where the coder writes source code. But as there are many layers in onion, there are many layers in software development. Writing the code is just one of them. Never the less, it's an important craft if the software is to be of any use and even more so if it is to be maintained.

Different Roles in a Full Stack Team

I don't think life is a box of chocolate. But it keeps surprising me never the less. In my case that means that I keep finding value in different activities. Such that I have not done myself or that my teams have not done very much. Maybe it could be best described as evolution.

I started as a coder. Although people didn't say it out loud (often), making modifications to 'the core' was more spectacular than making modifications to the graphical user interface. Mostly the illusion came from the siloed organizational structure. People who do something like to think they are somehow better than those 'other people' who do other things. Which is silly, of course, but still very human. :)

But anyway, I was a core developer. I worked with a big legacy core and could do magical things with it. I could create new features and implement new parts according to the details people gave me. Testing was something that was often mentioned as a valuable thing, but generally praise was given more to people who coded.

At some point I started to realize that testing is, in fact, important. My code wasn't perfect. My mind, the mind of a coder, was thinking how the system should be used. I didn't give a lot of thought to how the system wasn't supposed to be used. But many times users come up with very creative ways of doing things if the tool allows. When someone tested my code, it became better. It had less bugs. So testers were, and still are, useful.

When you work as a group or as a team it makes sense to have someone who makes sure that things happen. I don't think it needs to be a coach or Scrum Master (but it's ok too). More senior team member with right personality and skill-set can be even better.

Then lately, since Apple introduced iPhone, usability has become increasingly important. If the team has a dedicated designer, that's truly awesome. But even having usability built into the working practices is good. It's easy to get carried away with improving the algorithms and trying to write really clean code, but forget the fact that in the end someone should be able to use the system. And hopefully be able to do it without consulting a thick manual. So design and usability are important too.

Finally comes the role of architecture. It's possible to live without named architects, but I don't think it's possible to develop software with multiple teams if the architecture is neglected. Architecture might emerge, but it might not be the architecture you want to see. I dislike the idea of lifting architects to a podium or letting be live in an ivory tower. In my view architect could be a role. For the sake of clarity it would be just good that someone (even if team members take turns) will check occasionally the big picture and make sure all development efforts serve the grand plan. So I consider architects to be important too.

As a conclusion my view of different (necessary) roles in a team has changed over the years. Originally I thought only coders were needed, but now I know it takes a bigger family to grow flourishing software. And in this post I've intentionally scoped out many important business roles. Without proper Product Management and sales there probably won't be anything to develop. But let's leave something also for the future. :)

How we arranged a Hackathon

Hackathon was something that we had discussed for a long time and thought that it would be a nice event to arrange. I noticed that hackathon as an idea has been implemented in many forms but the one we used was borrowed from Atlassian. The idea was to give people 24 hours, no guidelines or boundaries besides the rule that one should present the results to the audience.

As this was the first time ever, we wanted to first check that is there even any interest for this kind of thing. We created an idea bank where people could 'deposit' their ideas on what they thought would be cool to try. When we had around ten ideas it was clear that we would do this thing.

Behind the scenes we set up a Hackathon Confluence space. It hosted an environment for people to register their team. Also it was a great way to arrange the electronic voting. Our technology unit head was already very much involved, but we wanted to get also our CEO as a sponsor and guardian for the event. After all, that's also a good way to guarantee that people are confident on spending their time for this kind of event and no-one will book meetings or customer visits for that day. When everything was clear, we announced the date and sent out invitation to everyone.

There were some necessary purchases to do before the grand day. For timing the demos (we had decided that each team would get a five minute slot to show what they had made) I wanted to get a Time timer. I saw one of those in a training and understood how simple yet brilliant the idea is. It's very easy to visualize how much time you have left with this little buddy.

Then we of course needed something to keep the people awake if they wanted to pull an all-nighter. Our company is not so big and I wasn't really sure how many participants we would get, so I got as ~50 Battery energy drinks.

And because everyone (should) know the Ballmer peak and we wanted to get awesome hacking results, we needed some alcoholic beverages.

Finally we wanted people to be constantly aware of the coming event, so we replaced our normal wall mounted status display with a countdown. It was very hard NOT to know when the Hackathon would start!

On the Hackathon morning we had a very short briefing about the rules. As stated already, there were no restrictions regarding the topics. Only rule was that you should be able to demonstrate the results the next morning, in a maximum of five minute demo. Presenting failure would be also very much acceptable, since when you ride a rocket, predicting the precise landing spot can be tricky. ;)

When the 24 hour time started rolling our idea bank had grown tremendously. We had almost 30 different ideas! And the number of teams was also astonishing. If I remember correctly we had 15 teams, some consisting of only a single person, but teams anyway. 

During the day the ideas got developed. We ordered some pizza for the hungry people just tried to root for everyone. It's worth mentioning that also people who were not themselves participating were very supportive for all the hackers.

As this was the first time, I didn't really expect people to stay up all night, but some teams did some late night coding. There were some hilarious pictures taken in the office during some very non-standard office hours. :)

When the next morning came, we had set up our demo environment. When the countdown reached zero, we started right away with the first demonstration.

The demonstrations were really high quality. It was really eye opening for people to see how much can be achieved in 24 hours when skilled and motivated people give their best. It is a huge potential that doesn't always get fully blooming. This is something to really pay attention to more.

As the master of ceremony I was really strict with this five minute rule. When the Time timer beeped, I started applauding. With some people the running out of time took them by a surprise, but almost everyone managed to present their ideas and results in time. It was clear that people had understood the idea that 'only the demo counts'.

Even though there were plenty of people physically present in our headquarters, we wanted to have electronic voting. We are a global company with multiple offices so it did felt like the right thing to do. We had ten minutes for the voting and then we announced the winners. They received the challenge cup, some personal rewards and of course awesome bragging rights for winning our first ever Hackathon. By the way, here's a picture of the cup:

All in all the event was a big success. Many of the ideas could be taken straight into production and unleashing people's potential was an awesome boost for the whole company. Definitely this is something to do again and I can really recommend arranging this kind of event if you have the possibility.