Building a successful start-up seems like a really cool idea – from a distance. I’ve used to teach a course about enterpreneurship, start-up, business models and alike. Although it was nice, I always felt that I’m a person who knows absolutely nothing about this. At least not in practice…
In this book, the original founder of Netflix tells his story about how he took the idea and made it into a product. He tells the story about how the idea hatched, how he, and his team, created a data-driven model of understanding their customers. The book is also about the struggles of start-ups – about taking on investments from the beginning and then being pushed out of the company. It’s about being able to understand what’s best for the company and what’s best for the individual.
I like the way in which the authors describes the story, and also shows a bit of himself: how he felt, how he wanted to build the company and how he decided when to leave (with grace!). I also like his ending of the book – Nobody knows anything! which is a saying that you never really knows what will and will not work in the end.
I recommend this as a Sunday reading to get inspired.
I’m a big fan of the Matrix movies, but well, to be honest, who isn’t:) I like the scene where Morpheus gives Neo the choice of two pills – one to know the truth and the other one to go on living his life as previously.
Well, sometimes I feel the same when I do my programming tasks – do I really want to know what the code does, or just make a quick fix and move on? I would say that it’s 50-50 for me – sometimes I feel like contributing and sometimes I just fix the problem and move on.
In this paper, the authors conduct an experiment to understand how and when software developers make mistakes. They find that “[the] study suggests that a relatively high number of mistakes are related to communicating with stakeholders outside of the development team. “
Having worked with metrics teams all over the globe, I’ve noticed that the communication with the stakeholders is often the largest problem that you can have. The stakeholders don’t speak “requirements” and we do not understand “wants” of the stakeholders. But, well, it’s not what the paper is about.
What I like about the paper is the systematic approach to the study – using experiments and a technique for teaching the developers how to work with their limitations. This is what the authors recommend as remedies (quoted directly from the paper):
Know your own weaknesses. Every developer is different and struggles with different concepts. Our analysis shows a variety of types of errors that developers make. Developers becoming more conscious of the human errors they commonly make and actively checking for these can help reduce errors.
Use cognitive training. We have shown that using cognitive training, like the OODA loop, seems to help decision making and can reduce the human errors a developer makes.
Simplify your workload. One of the biggest causes of human error reported by the developers in our study was the complexity of the development environment. Reducing the cognitive load by simplifying the complexity of the development environment could reduce human errors. Actions such as minimizing the number of simultaneous development tasks and closing down unnecessary tools and windows can help reduce the cognitive load.
Communicate carefully with stakeholders outside your team. Our study suggests that a relatively high number of mistakes are related to communicating with stakeholders outside of the development team. Ensuring that communication is clearly understood seems important to reducing mistakes.
Initially, I did not really think that I would put this article on the blog. I actually thought about using it in my writing advice page. However, I’ve read it and then I realized that it’s actually more suitable for this blog.
This article shows how we can classify software engineering research. It has a nice framework described in Figure 1. It organizes the framework around the concepts of who the main beneficiary is – e.g. human, system or researcher (yes, it is a different category!), type of research contribution and which research strategies are used.
It’s an article that complements the work of our colleagues from Lund University on the design of design science research studies and the construction of graphical abstracts.
Although the work seems to be obvious when you are a seasoned researcher, I need to be reminded sometimes about what kind of study that I want/need to conduct. Therefore I recommend this as a reading to both PhD candidates, master students and also advanced researchers. Using the classification scheme will definitely help us to understand each other better and to reduce the burden of paper reviews!
As part of my weekend reading I took on a book about cultures. Not a typical reading of mine, but I though I would give it a try. This book is about differences in cultures from the perspective of rules, laws, principles. It is a common knowledge that some societies are very relaxed (e.g. Scandinavia) whereas some are very strict (e.g. Singapore). Commonly, we also know that the loose societies are more creative, whereas the more disciplined ones are very, well, disciplined.
This book also makes a point that it’s not as simple as that. This is not a linear relationship and there is some golden middle. Just being a loose society does not guarantee innovativeness and just being strict does not guarantee discipline. People need a “lagom” (here is a good Swedish word, meaning just right, in the middle, just enough, not too much and not too little) set of rules and looseness in the society.
When I read the book I thought about well-functioning organisations. In the companies and teams that I visit (or used to, before the pandemic), I often saw teams that were working together well with some degree of looseness, but not completely without the rules. They tend to perform well and function well when all team members understand the goals and rules of the game. I’ve also seen teams that are not able to function at all. They do not respect each other, have no respect for rules and provide no support for each other. They are “too loose” and therefore they are groups, but not really teams. At the same time I saw teams where the narcissistic boss controls everything and everything needs to go through the boss. They do not produce much, trust me.
However, there is also one more aspect – it’s where you come from. I, for that matter, cannot work in a self-organising team. I just don’t know how to find my place. One of my friends told me once – “Either you lead, or you follow or you get the hell out of the way”. Well, I’m more for that kind of the rule. Following is nice and I like it, but self-organising is so-so.
I’m actually part of a self-organised team in one of my assignments. I don’t know what to do there, I rely on a friend from the team to tell me when is my turn to speak and if I should say something or not. He also tells me when it’s a good time to do things and when it’s just a discussion. I’m not providing the name of the friend, but I’m super happy that I have him!
To sum up, I really recommend to read this book as it provides a bit wider perspective on rules in societies than the most common books from the organisational theories. It is about a normal person like me trying to find a place in life (well, by now I would actually think that this is easier, but maybe I’m just wiser to realise certain things).
Thanks for listening and tun in for the next blog post.
This week we had the possibility to give a webinar about how to work with large scale measurement programs. The webinar was dedicated for everyone who works with software metrics and would like to get more impact from that work.
It is not so much about the numbers, it is about the impact and what the numbers mean. The webinar that we present, provides a good understanding of how to make this impact. Based on our experiences, we chose all one needs to know to implement a measurement program in few weeks rather than years.
The webinar has been recorded and is available at this link: https://www.youtube.com/watch?v=2ChaVT_3djE&feature=youtu.be
Recording from the webinar about how to succeed with measurement programs.
Engineers and scientists love to measure. We measure complexity of software, its performance, size and maintainability (just to name a few). We need these measurements in order to construct software, manager organizations or release high quality, high reliable products. However, there is a difference between measuring software aspects and using the measures in decision processes. In this talk, we present the concept of measurement program, measurement system, information quality and indicator-triggered decisions. We show what to consider when setting up measurement programs and provide a hints about the costs and benefits of having the program. We end the talk with presenting recent research results from Software Center, where we combine measurements and machine learning to speed-up software development.
A while back we gave a webinar with a similar title, where we focused on the questions concerning the measurement infrastructure, visualization and assessment of the measurement program. The ACM webinar is presented here:
Abstract:
Software Engineering is one of the newest engineering fields with a growing need from the society side. The field develops rapidly which poses challenges in developing sustainable software engineering education – allowing the alumni to be effective in their work over a long period of time (long-term impact of the education) and keeping the education attractive for the potential students and industry.
The objective of this presentation is to describe the experiences from using business intelligence methods to develop, profile and monitor software engineering education on the master level. In particular we address the following research questions:
Which data sources should be used in developing a profile of a master program?
How to combine, prioritize and communicate the analyses of the data from the different sources?
How to identify barriers and enables of attractive sustainable software engineering education?
The results are a set of experiences from using data from the national agencies in Sweden (e.g. the Swedish Council for Higher Education – UHR, the Swedish job agency – Arbetsförmedlingen, international master education portals – mastersportal.eu) as input in development and evaluation of a master program in Software Engineering at University of Gothenburg.
The conclusions show that using the available sources lead to creating sustainable programs and we recommend using the data sources to a larger extent in the national and international level.
