Although most teams I know try to produce clean code, it seems to be a hard thing to keep a project clean while it grows. I began to wonder: How much clean code is really out there in the wild? Followed by: How can a project even be considered as clean? So I picked some famous open source projects and analyzed them!

What makes a project clean?

First, let’s summarize what I did: My first intent was to check a static code analysis tool like SonarQube, but I could hardly find an open-source project which also published the results of such tooling. This is when Metrilyzer was born. An analysis tool of mine (private projects again^^) which can read almost every Java-based project to do some data analysis on it. At first, I focused on the following metrics:

• Classes per package
• Lines per class
• Methods per class
• Lines per method
• Parameter per method

Of course, they are not enough to consider a project as “cleanly coded” but in my opinion they give a good indication on code modularity and compliance with single responsibility principle. This is one of the hardest things to accomplish from my point of view. So using these metrics you can at least see clearly when a project is not clean coded. 😉 Here are the results.

Cassandra, ElasticSearch, Spring Boot – The hard figures

The four tested projects are Cassandra 3.11, ElasticSearch 6.5, Spring Boot 2.1 and Neuronizer Notes (an Android app of mine). In the boxplots you can see the number of lines per class (y-axis) per project (x-axis). N is the number of classes in the project (which could be analyzed by Metrilyzer). The maximum values are somehow obscured so that the rest of the plot looks better, but you can still read them in the table. If you don’t know how boxplots work look here: What a Boxplot Can Tell You about a Statistical Data Set

You can see that most of the classes are very small and more than 75% of all classes are smaller than 100 lines of code. Despite every project having a couple of huge classes. It seems like the bigger the project, the longer the longest class is. Not very surprising, but things get more interesting when you compare different metrics. Let’s take a look at lines per method for example:

Like the classes, most of the methods are very small and more than 75% are smaller than 15 lines per method. Despite a large number of methods Spring Boot does a very good job at keeping them small. With a maximum of 54 lines per method. Also interesting is the correlation between N in the two metrics (which is the average number of methods per class):

• Cassandra: 19393 methods in 4162 classes = 4,65 methods per class
• Elastic Search: 36027 methods in 8021 classes = 4,51 methods per class
• Spring Boot: 14140 methods in 5963 classes = 2,37 methods per class
• Neuronizer Notes: 571 methods in 173 classes = 3,30 methods per class

I have to mention that getter and setter methods are excluded so in reality, the numbers are slightly higher (see metrics at the end). Neuronizer which is a small application has an easy time at keeping classes and methods small. As you can see Cassandra and Elastic Search do have a harder time. But Spring Boot is doing very well in comparison to the others. They have even smaller methods than my little android app. Okay, now let’s take a look at the most problematic classes.

Pinning down problems

What you can see here are the five most biggest classes for each project.

What I recognized at first were the test classes. Since the teams out there (at least those I have been part of) care less about test code quality vs. productive code quality it makes sense they can get very long. You can also see that long classes lead to long test classes. Elastics InternalEngine and InternalEngineTests for example. As test classes grow it gets harder and harder to keep them maintainable, so a well thought-out model for test classes should be applied. Regarding large test classes, I can recommend the article Writing Clean Tests – Small Is Beautiful.

Another important thing you can learn from this table is where the application has not been modeled carefully. Cassandras StorageService, for example, has a very generic name and became the biggest god class in the project. Elastics Engine and InternalEngine had a similar destiny. These classes could easily be separated in a couple of subclasses, but as they are now they just cannot be clean.

For the interested guys out there, here are the other metrics in an uncommented form. They will be mentioned in the Conclusion though. All visualizations have been done using goodcalculators.com.

Conclusion

Probably, you already thought in the beginning: You can’t put hard figures on the rules of Clean Code like “Oh boy, this class here is 5 lines too long! Are you dumb?” But you can use these metrics as an orientation. You can aim for the Pareto principle. For example: Refactor the highest 20% of each metric. Try to be in the lower 80% with all your new code. When you reach 100 lines of code in a class, for example, there could be better ways to modularize that piece of code. Here are the 80% boundaries for each metric (based on all analyzed projects):

• 80% of all classes are smaller than 100 lines
• 80% of all methods are smaller than 12 lines
• 80% of all packages have less than 25 classes
• 80% of all classes have less than 8 methods
• 80% of all methods have less than 3 parameter

Despite this being a rather shallow analysis on the topic of clean code, the results were quite interesting. Using Metrilyzer on a single project with tailored visualizations can be even more helpful to improve modularity and to locate trouble spots. Maybe you want to give it a try to analyze your own projects. If so, I would be glad to hear from you 🙂

Greets, Domi

Day 1

Dear diary, it’s the first day on the Hackathon. Dominik, Danny and I chose to work on the cloud of clouds projects. Sören is also with us, but he works on another project with some friends. The idea behind cloud of clouds is, that you are no longer limited to online storage. Instead, your data is distributed across all cloud provider. So no single cloud provider owns your data! In two days we can not develop a complete client with a CRUD implementation. As a result, we decided to develop a library and a simple CLI that allows uploading a file.

Night 1

Actually, there’s not much to tell. Because we decided to sleep for a few hours the first night 🙂

Day 2

Dear diary,
Dominik, Danny and I decided to do some kind of pair programming. We are just using Danny’s Mac Book for coding – no other pc is used! Funny… cause everyone is looking at us because the three of us cuddled up in the sleeping-corner to program in TDD style. Jop, you understand correctly we are doing test-driven development on a Hackathon! Actually, no one of us has done that before, so it’s awesome that we are working together on one pc. You might think “WTF TDD on a Hackathon?!” and you are right… It’s uncommon to write tests on a Hackathon, but we think it may be a great experience and we can learn a lot from it! In the end, a Hackathon is not about winning, it’s about learning!

Night 2

We are getting closer and closer to full implementation. Developing in TDD style has changed our interfaces, which we created at the beginning. Those were magic moments! I’ve never developed TDD before, but it’s impressive to see how the test determines the shape of the code.
But we still haven’t connected Dropbox or Google Drive. However, the time is running out! It’s time to unpack our secret weapon, the Crack-Hoe-Pattern. You’re probably wondering what this is ? It’s a design pattern for software that we’ve been using for some hackathons. Using the Crack-Hoe pattern you can achieve maximum encapsulation of ugly code. You put everything into a class called Crack-Hoe. Using a single access point, the magic method, the ugly code can then be executed.

But despite our secret weapon, the crack-hoe pattern, we had to sleep in shifts to get through the implementation.

Day 3

Phew… we made it. Shortly before 9 am we implemented our use case to upload a file, as well as a CLI client. The pitches take place in two rounds. In the first round, you have 5min time to convince the jury. The 20 best ones are allowed to pitch on stage for 3 minutes. But there are several hours between round one and round two. So time to catch up on some sleep!

The 20 best teams will be presented… and… and… and… Oh no! We are not among the 20 best 🙁 But hey, you can’t win every hackathon! Also, it has something good not to have to pitch again, you can drink a beer with a good conscience. So, we all sat together for a beer and listened to the pitches of the other teams 🙂

BTW Leon never arrived. But we still love him very much 🙂

She is a strong personality, an overachiever, a hero, a secret leader – even if not all of the above apply to your teammate, she still can be one. In this blog post, I will try to make you understand, why those (hereafter called) overachievers carry a huge risk for an agile team (and company) inside. It is easy to ignore, tolerate or just accept, but if you and no one does anything about a team-substance like this, it can react poisonous when combined with wrong elements. Dare to let it be as is, and you will suffer the consequences, just like the rest of your team. The way of least resistance is not always a good choice.

But what is so bad about it?

Depending on the overachiever and the team, the following things are possible to happen to some extent:

• Skill development, success, and outcome should be team achievements. If only one person gets all the credit or is the go-to-person for everything, the rest of the team starts feeling discouraged. Why try harder, when you can only do your job, hide behind her and work off the 9to5-duties? Falling into this behavior, makes your work ultimately seem meaningless. Friendly colleagues, a more or less appropriate salary or a nice environment will not motivate on a long run. If you lose the mission, why stand up in the early Monday mornings at all?
• You wonder how she does it? She might never let you know. Overachievers tend to take over the tasks, with the mentality of “If you don’t do it yourself, it won’t be done (properly)”. Like this, she thinks (or says): “By the time she explains it to you or someone else, she has it done by herself”. The latest, when you hear one of those two phrases, your alarm should go off! She eagerly maintains her knowledge island and makes it grow. So the team success depends on her, sometimes only on her. This puts the team and the organization into a bad place when she feels like she wants “more”, is on vacation, simply not there, or even leaves. In Agile Teams, this is worst case in action! Because…
• It is easy and seems intuitive to mismanage: teams and even companies die in the long run due to encouraging overachiever to save the day over and over again. This is what I saw going down at Goodgame Studios back in the days: They get the feeling that they must be held within the team, or it will fail. Bad/ inexperienced managers tend to think they need to give everything to keep them in the company. Suddenly, that overachiever finds herself as people-manager, not able to perform like in her original profession. As a result, the company traded a highly professional developer (or whatsoever) for a “bad”-leader. That’s a lose-lose-resolution. For a manager, it is easy to overlook the short-sightedness of the success of such an overachiever. Therefore, it is important that everyone understands: A mismanagement of such overachievers is a threat to sustainable success.
• Overachiever have their specific characteristics. Your teams’ approaches and results will lose it’s exploratory diversity when she is always “in the lead”. Remember: the Product Owner brings the “why”, the Scrum Master the “how” and the team the “what” (see https://www.boost.co.nz/blog/2018/04/successful-scrum-team-product-owner).  By having the same approaches and doing the same type of work, you will lose the important ability of scrum teams: solving unknown and complex problems. Work starts to feel highly repetitive and – again – meaningless. The rest of the team starts mirroring her, by also over-/underthinking stories or spending too much/not enough time on general discussions. Moreover, the personal development of each team member will suffer, when no one breaks this pattern.
• Team member feel like they cannot contribute, so they start letting the overachiever make all the talk-work. This ultimately leads to letting her also do all the thought-work (because it’s convenient)… And even though it’s an overachiever in the lead, she might not be aware of the specifics of her “power” and influence. The team ends up with getting poorly directed. “People [working for an overachiever often] do not understand where they are going. They’re just following the walk of this turbocharged leader, who doesn’t direct the team but focuses on output. They get annoyed, exhausted, and feel that they need to second-guess what the leader wants because they’re not being told.”, Goleman, D. “Leadership That Gets Results,” Harvard Business Review, March-April 2000.

What to do?

The main objectives are:

• Let the overachiever share his knowledge (to reduce knowledge island risk),
• Give every person equal opportunities to provide their input (to live collaboration and achieve diverse approaches to master complex problems).

Be sure: The overachiever in your team is not a bad person! She aims for only the best for the company and product. Of course, to her, it seems that she does it very well! Remember, you are not enemies or opponents, but teammates who need to figure out how to work best together and achieve sustainable success (and fun)!

Step 1 – Out of your comfort zone!

Well… not (only) the overachiever is the reason why change needs to happen. What does Michael Jackson say again? Start with the man in the mirror! “If you wanna make the world a better place, take a look at yourself and then make a change!”

Speak up, take action, demand change, to improve communication and vary methodologies, and don’t fall into the dangerous pit of self-pity and couchpotato-convenience. See this paragraph as a start for your journey, for letting your team grow together, a bunch of equals. The team needs someone like you. You will be the one who must be demanding change, if your Scrum Master, Product Owner or Lead doesn’t do it! It means, if not you, no one will. The fact that you feel/ realize that this might be or become an issue in your team, you are the chosen one.

But how, you ask? Expect and demand baby steps! There will not be a “big bang”-change and everything is “good”: One step after another. Even small changes can have a big impact.

Step 2 – The (Scrum Master) Talk

I know, the Scrum Master is not holding any leadership position and yet, she is the one who should facilitate and host team gatherings and meetings. She is supposed to take care that exactly this does not happen. Her influence is limited by the willingness of the team, so give her reason and solid ground to work on equalization within the team. Maybe she is not very experienced yet, or she also just accepted things how they are (aware or unaware of what it means). You should find the talk with her about what she thinks about the situation, and what you can do to lift up the team spirit and sustainability! There are many things she can do, to give everyone the change to commit their ideas, opinions, and qualities.

Ah… and by the way: Even if it is only you, who feels a bit outside of the system (and everyone else is kind-of ok), you still should make your point to her. A Scrum Master should also be the go-to-person, for a team members issues, and help to get all the potential on the street!

Step 3 – Remind and demand Agile Principles

Do I really have to say this? Agile teamwork is about dialogues and collaboration. Embrace every individual in your team as equally important and qualified, as a potential if not experienced (yet). Collaborate, interact, and get the best out of every single member! See the first freaking line of the goddamn Agile Manifesto: “Individuals and interactions over processes and tools” ( http://agilemanifesto.org/ ). Such simple and undiluted wisdom… It makes me cry every time I have to remind people to think about it. It should be burned in your and everyone’s (developer) brain. It is not negotiable or relocatable. This should be surer than day follows night. Before you try to enable the potential of your team with methods or tricks, consider talking about the issue openly with the whole team. Make them understand why embracing and supporting overachiever-ness means to risks sustainable success. A retrospective meeting is a very proper time to place your concerns! Agile teamwork is based on trust. Give your team (including the overachiever) the benefit of trust and honesty.

Step 4 – Bring in opportunities for good behavior

Train your instinct and get a sense for the right moments to embrace collaboration. In discussions and talks, notice who is silent and doesn’t commit to active collaboration. Encourage them to speak (up), i.e. by actively asking them about their opinion. If you know your team members well, another more sneaky way is, to bring up a topic they are passionate about, make a connection and/or take an opposition-position, so you tease them out of their lethargy (you can also (later) be honest about your evil-genuine plan to get them into the conversation). Continuously place suggestions to collaborate or to do pair programming, because sometimes a little push in the right direction is all that’s needed. Yes, also you as a teammate can do this – no need for a Teamlead, Scrum Master or Product Owner to make those moves.

Step 5 – Remove opportunities for bad behavior

There are several methodologies to give everyone the opportunity to provide their own input and to also let them talk without being interrupted, discouraged, or subdued. Usually, your Scrum Master comes up with those ideas, yet sometimes they also need a little inspiration. Don’t worry. It doesn’t always need to be a big thing. Actually, mostly it can already be enough to request a democratic vote, to let everyone think about something themselves and/ or add their thoughts. But for some bigger topics, you might think of the following two approaches: A neat little allrounder method is the silent brainstorming, with a followed presentation-time. Everyone has around 5 to 10 minutes to make up their mind and write it on sticky notes. Afterward, when everyone is ready and done, each participant gets a limited time to present the sticky notes, and do something with them, according to whatever purpose the brainstorming was about. Like this, everything is limited to a specific timeframe and as you can see everyone provides in the same manner. You will find your team in situations where brainstorming can be of value. Instead of just throwing in ideas (and get overwhelmed by the overachiever), you can suggest silent brainstorming. Something that helped me a lot to manage bigger teams, with a multi-dimensional problem, was the following: Split the team into two- or three-people-groups. Each group targets one part of the topic and presents it to the rest of the team members. If you want more people to provide input to each aspect do the following: Instead of only dividing the team into smaller groups, you also divide the room/ location into different subject-islands. Each island has one subject-host (preferably the overachiever is also a subject-host). Every person/ group spends around 5 to 15 minutes on each island, while the host notes the important parts of the talks/ discussions. After every group talked about every subject, the hosts present the results of the island. This was most helpful at retrospective meetings or to get solutions for highly complex features or goals.

Always remember: You are not enemies, but teammates!

I hope I could give you a little sense of how you can handle the overachiever in your team. Of course, there is no such thing as a clear path to teamwork-city, but if you take my words as a starting point for orientation, you maybe find the right way. Don’t hesitate to comment or write a direct mail to me, when you have any further questions or feedback.

Enjoy, collaborate and succeed!

Soeren

during my studies I had to analyze the NoSQL database Cassandra as a possible replacement for a regular relational database.
During my research I dove really deep into the architecture and the data model of Cassandra and I figured that someone may profit from my previous research, maybe for your own evaluation process of Cassandra or just personal curiosity.

I will separate this huge topic into several posts and make a little series out of it. I don’t know how many parts the series will contain yet, but I will try to keep every post as cohesive and understandable as possible.

Please forgive me, as I have to introduce at least a couple of terms or concepts I won’t be able to describe thoroughly in this post. But don’t worry, I will be covering them in an upcoming one.

What is Cassandra?

Cassandra is a column-oriented open source NoSQL database whose data model is based on Big Table by Google and its distributed architecture on Dynamo by Amazon. It was originally developed by Facebook, later Cassandra became an Apache project and is now one of the top-level projects at Apache. Cassandra is based on the idea of a decentralized, distributed system without a single point of failure and is designed for high data throughput and high availability.

Cassandras Data Structure

I decided to begin my series with Cassandras data structure because it is a good introduction to the general ideas behind Cassandra and a good foundation for future posts regarding the Cassandra Query Language and the distributed nature of it.

I try to give you an overview how data is stored in Cassandra and show you some similarities and differences to a relational database, so let’s get right to it.

Columns, Rows and Tables

The basic component in Cassandras data structure is the column, which consists classically of a key/value pair. Individual columns are combined in a row and uniquely identified by a primary key. It consists of one or more columns and the primary key, which can also consist of one or more columns. To connect individual rows describing the same entity in a logical unit, Cassandra defines tables, which are a container for similar data in row format, equivalent to relations in relational databases.

However, there is a remarkable difference to the tables in relational databases. If individual columns of a row are not used when writing to the database, Cassandra does not replace the value with zero, but the entire column is not stored. This represents a storage space optimization, so the data model of tables has similarities to a multidimensional array or a nested map.

Skinny and Wide Rows

Another special feature of the tables in Cassandra is the distinction between skinny and wide rows. I only described skinny rows so far, i.e. they do not have a complex primary key with clustering columns and few entries in the individual partitions, in most cases only one entry per partition.

You can imagine a partition as an isolated storage unit within Cassandra. There are typically several hundred of said partitions in a Cassandra installation. During a write or read operation the value of the primary key gets hashed. The resulting value of the hash algorithm can be assigned to a specific partition inside the Cassandra installation, as every partition is responsible for a certain range of hash values. I will dedicate a whole blog post to the underlying storage engine of Cassandra, so this little explanation has to suffice for now.

Wide rows typically have a significant number of entries per partition. These wide rows are identified by a composite key, consisting of a partition key and optional clustering keys.

When using wide rows you have to pay attention to the defined limit of two billion entries in a partition, which can happen quite fast when storing measured values of a sensor, because after reaching the limit no more values can be stored in this partition.

The partition key can consist of one or more columns, just like the primary key. Therefore, in order to stay with the example of the sensor data, it makes sense to select the partition key according to several criteria. Instead of simply partitioning according to for example a sensor_id, which depending on the number of incoming measurement data would sooner or later inevitably exceed the limit of 2 billion entries per partition, you can combine the partition key with the date of the measurement. If you combine the sensor_id with the date of the measurement the data is written to another partition on a daily basis. Of course you can make this coarser or grainer as you wish (hourly, daily, weekly, monthly).

The clustering columns are needed to sort data within a partition. Primary keys are also partition keys without additional clustering columns.

Several tables are collected in to a keypsace, which is the exact equivalent of a database in relational databases.

Summary

The basic data structures are summarized,

• the column, consisting of key/value pairs,
• the row, which is a container for contiguous columns, identified by a primary key,
• the table, which is a container for rows and
• the keyspace, which is a container for tables.

I hope I was able to give you a rough overview of the data structure Cassandra uses. The next post in this series will be about the Cassandra Query Language (CQL), in which I will give you some more concrete examples how the data structure affects the data manipulation.

Cheers,

Leon

So as we sat down to brainstorm about possible projects we came up with one that solves one main issue in the charity-ecosystem, connecting the concept of blockchain with charity – two worlds connected – we called it “Chario” and registered for EXXETAs challenge.

We developed an app for middlemen (Agents) and a web page for benefactors, both connected through a backend that facilitates the data between them. With our system, we enable benefactors to choose where exactly to donate to, then chose one out of several possible donation-types (material or money) to finally trace the donation throughout the process, till it finally reaches the beneficiary (proven by a photograph). After 24hours of creative teamwork, coding, struggling and getting-shit-done, a huge amount of coffee and a 15 minutes pitch to the EXXETA team we were done, and yet we somehow managed to hold on till the very end. Don’t underestimate the pressure you’re feeling and the effect of sleeplessness on your nerves when you didn’t sleep for around 36 hours, facing a pitch in front of 200 people. Somehow, we gathered all our inner forces and simply just performed. The rest still seems blurry somehow: We didn’t expect to win anything, so we were surprised, yet very very happy and thankful as Matt was standing on the stage, shouting out our name, saying we won the Category-Price “Connect the Worlds”:

Not knowing what huge effect this prize will have on our team experience and future plans… in this blogpost, I will try to give you a small insight of what we learned. Be aware though, this is just one brick on the wall. There were side-stories and a lot going on between us, the other participants, the amazing EXXETA team, Berlin, clubbing, cocktails, accommodation issues, and so much more… all in all, this was a trip we’ll hopefully never forget.

What happened so far?

Obviously, our EXXETA-Go-To-Guy Matt couldn’t wait to get the workshop started, so he directly added Danny and me on LinkedIn. Quickly we exchanged email addresses and phone numbers. We agreed to make a call with all Billige Plätze on Skype which turned out to be casual and welcoming, our excitement grew. In the aftermath I can only assume how much energy went into planning and organizing the workshop, in the background Matt and his colleagues must have started right away – impressive – what an eager team! Soon they sent us successively more and more info about what’s about to come. The last notice was, that we should re-prepare our pitch from the hackathon. Like most of the projects born at hackathons, there has no further work been done for Chario, even though it was, like all the times, also a project we’d like to keep working on… Since only Dominik, Leon, Danny and I attended the hackathon and won the price, it was more than just nice that they also invited the rest of our real Team “Billige Plätze”. Hence, all of us are on the way to Berlin right now, looking forward to the next days and experiences.

And as we are on our way to Berlin now, I’m getting started with this field report, my diary of our experience of the workshop with EXXETA…

Who is EXXETA?

With more than 750 employees EXXETA AG is a big international player in Technology Consulting for the Energy-, Automotive- and Finance sectors. They have several offices all around Europe, most of them in Germany. The team that invited us is known for innovative and unconventional, yet successful methods and measures to get things done. They are situated in the WeWork Coworking office in Berlin – next to the Sony Center. During the workshop, we got to know a few colleagues of Matt and were amazed by the casual, young spirited, yet professional style.

Day 1

The Factory

We were a group of 12 plus the EXXETA coaches. First stop was the Factory. The Factory is an amazing Coworking space for innovators and startups that grow a community by carefully choosing who joins the network. Not only are the offices well designed and furnished, but also it scores with features like a ball pool, foosball, huge kitchen with coffee for free, space for networking and getting to know like-minded people. There we met the IoT and Blockchain company builder Next Big Thing.

Meet&Greets

Next Big Thing – What does a Company Builder do?

Next Big Thing (NBT) specializes in IoT and Blockchain startups to give them a quick and smooth start. This is especially helpful when it comes to startups with hardware-based innovations. NBT supports a startup not only with access to a big network of startups and investors, but also pays you a fair monthly salary and helps you to deal with topics like IT-security, technical certification and standards, legal regulations, bureaucracy, HR administration, accounting, marketing, pitch-coaching, recruiting, office infrastructure, workshops and much more. Also, they have a highly-specialized senior developer team, supporting you with additional operative workforce to get your product onto the market. They developed a program called “Venture Design”, where NBT leads you through all the necessary steps for building your own company. My key learning of this visit was, that all of their startups ended up with another product as they actually began with. Therefore, they rather decide on a team or person, than the idea that got pitched in the first place.

Entrepreneur Alexander Barge

Next station was lunch, where we met Alexander Barge. Alex is a highly experienced Entrepreneur and deeply integrated into the Berlin startup scene. There we had the opportunity to place our questions in a personal atmosphere and get first-hand advice. So after we got introduced to the complexity of founding, Alex managed to motivate and encourage to start something new, thanks to his enthusiasm and up-beat. As a CTO and Co-Founder himself, he made it clear, that you can “just start”… of course it is a lot of work, and you will never lose that bad conscience of “actually I should be doing something” whenever you’re not working, and eventually you’ll fail at the beginning – but there will be progress, excitement, a lot to learn and eventually a chance for success. It seemed a bit like what I told you in my previous blog post (“How to start and learn coding”) – all you need to do is get your a$s up, start and stick with it as much as possible. So next to the delicious food we dined that fantastic enthusiasm.

Blockchain Lab at GIZ

Since the Chario-Concept was driven by a non-commercial idea and we mentioned the idea should be realized with blockchain-technology, the next stop was the Blockchain Lab at the GIZ (German Corporation for International Cooperation GmbH). Franz von Weizsäcker and his team are trying to find sustainable use-cases for blockchain technology. With the technology of Blockchain, it generally feels a bit like there is a solution without knowing the problem it can solve yet – so it needs specialists like Franz(s team) to find out where to place this technology without risking an alienating effect.
We asked what they think about our idea and if it seems realizable. The answer made clear, that in the charity-ecosystem there is a big resistance towards change, especially when it means that i.e. middlemen might earn less than before – yet, the use-case of connecting blockchain-powered traceability with donations is very promising and powerful.

After a short break and retrospective come-together, Matt introduced the first canvas to get a business model sharpened.

Working with the Value Proposition Canvas

We started with a canvas which is supposed to help to focus on the user’s needs and then find possible solutions. Here you can find a nice and simple explanation of the canvas:

How we did it: Field by field, we were timeboxing silent brainstorming-phases of around 3-5 minutes, where everyone wrote the ideas on Post-Its. Followed by putting those on the canvas, one by one. Each session continued with a short discussion about discrepancies and different opinions until we go to the next field.
We were working through the canvas in this order: Jobs => Pains => Gains => Pain Relievers => Gain Creators => Forming the products and services. The moment you are done with the canvas it is useful to go over it again, cluster it by topics, and at the end prioritize the features to decide whether it is an essential part of the Minimal Viable Product (short MVP) or not. Here is our result – a bit messy, and yet we all like it:

Our First Little Pivot

Within this process, we figured out that we got to change something about the product-idea since there are two main issues

• Issue one – Transparency: Why would non-governmental organizations (short NGO) and their middlemen cooperate with us to make the effort and implement transparency features in their processes?
• Issue two – Proof of good work: How can we know who needs the donations?
  We learned that a service/ system or product that solves all the issues would be too big as a start, so we wanted to pin down possible features for an MVP.

And even though we found possible solutions for those two issues, we realized that none of us are somehow eager to dig deeper into any of them. Motivation is key! So based on our first result we decided on developing a system that motivates future benefactors and helps NGOs to raise more money. The idea went a bit into the direction of something like payback for NGOs, but better… of course 🙂

After an exciting first workshop day, the team ordered pizza which got accompanied by insights of EXXETA from the development team leader Sébastien Jelsch. He was stating that, if you don’t want the insecurity of a startup, yet work alike, in a team of people who want to make a change, you may check out what’s in the job listings on their page 😉

Day 2

The second day was all about getting our first business model-draft done. After a short tour through the amazing Coworking office WeWork, we got to work, more focused than ever, quickly filling up the Value Proposition Canvas and sharpening the concept.

Business Model Canvas

The Business Model Canvas is a lean method to nail your business model down to its core. Find out more about the canvas here:

We easily went through this canvas. The product and the organization around it was clear to us, so there was hardly any reason for discussion. The Value Proposition Canvas was a perfect preparation for this one. Here is our result:

The next step would be to go over it and distill the core out of our brainstormed-content.

What is the LVLX Summercamp?

During our lunch break, Matts boss came around, wanted to know how we like the workshop and told us about the LVLX Summercamp. It is a paid six-weeks-program for (mostly) students who want to focus on their idea or product and get supported by EXXETA and their “high-society”-partners. If it wouldn’t be so entirely impossible for us to take part, we had not hesitated one millisecond. I’ll be following the outcome of that workshop, knowingly that all the potential they gather and own, there got to be some pretty impressive results.

One Metric That Matters (OMTM)

To get back to work Christian Grimm from EXXETA gave us an important side note: Focus on the right thing is essential for the success of all the phases a startup goes through. And the argumentation is simple: You don’t have a lot of resources and time, so the only way you can get more of each is by using the bit you have for the right things. Defining one metric / KPI can drastically help to consequently align the work and focus of a team. In the beginning, it’s the key to look for “softer” or money-unrelated KPIs, like positive/ negative-feedback-quota or percentage of MVP-features, developed, rather than sales or ARPU. If you are interested in reading more about this, I can really recommend this blog: Lean Analytics Book.

The Timeline

With this at hand we managed to finish our first self-developed Business Model Canvas, and so we moved on to the last part of the conceptual day: the timeline. Nearly as easy as it sounds, you define three time-intervals and decide for each of those phases your goal, invest, team size, OMTM, hypothesis, important tasks, open questions and possible obstacles.

Intrapreneurship

The following talk of Philipp Stork was about a question that big companies started asking: “Why can’t we be as quick as a startup?” The phrase “Intrapreneurship” indicates that those companies should develop an entrepreneurial mindset within its employees and empower them to pursue their demand for creating something new, in the name of the employer. This sounds like a pure win-win situation, you maybe think? Research shows that there are companies that fail to implement a startup character within a motivated team, or sadly still don’t want to see this “unconventional” method as a valid solution. Yet when a company goes that way and really empowers their Intrapreneurs, there is a chance of success.

Entrepreneurship

Since most of the meet&greets, talks and tasks of the workshop were about sharpening our concept for a possible startup, in his keynote, Matt managed to find the right words about what it takes to be an entrepreneur. He broke it down into three main-skills:
1. Think outside the box: Because there will be moments you couldn’t foresee, and you have to react, there will be problems you have to solve creatively and pragmatically, you got to be able to improvise and surprise!
2. Be focused: Just as mentioned before – use your resources effectively. As an entrepreneur you can only set small accents, yet if you place those correctly, you can make a change, because you have the freedom from all the internal politics, bureaucracies, hierarchies and everything else that slows down bigger companies, but a big chunk of motivation, team-feeling, including the responsibility to quickly launch your product with the available resources, and beat incumbents to market.
3. Don’t get discouraged: Especially after the first few days / weeks it comes again: The daily business – just like in a relationship, you will have to make the transition from “having a crush” to “being in love”. On a journey as a founder, you meet a lot of naysayers just as sure as failure will happen. This should never be a reason to think about stopping, but to stand up, learn from mistakes, filter between good and bad advice and have the courage to learn and maybe change a plan quickly.

There is plenty of literature about how to get started with your startup. Here is a Must-Read for anyone who is actually thinking about it: Startup Playbook by Sam Altman.

Afterward, we sat down and enjoyed a wonderful cold beer in the Coworking space WeWork, where we stayed a bit longer, till we finally had to leave, and the evening celebration got started.

The Sum Up

So what do we take away from this two wonderful workshop-days?
First of all, we gathered a lot of insights when it comes to founding, depending on what product you work on. Secondly, we developed an idea that we might pursue in the close future. Thirdly the EXXETA team managed to pack our bags with the right tools to work on further ideas, what we’re going to try out at the next hackathon or other future projects. Last but not least, we got a glimpse of the Berlin startup ecosystem and found a lot of new friends – all of us were purely amazed! We, the team Billige Plätze, had a very fruitful, intense and important time with each other, bringing us together more and more. Who knows what maybe getting started thanks to this experience…

Artificial Intelligence as a Service (AIaaS) is third-party offering of artificial intelligence, accessible via a API. So, people get to take advantage of AI without spending too much money, or if you’re lucky and a student, no money at all.

The Microsoft AI Platform

As already mentioned above, we have used several Microsoft services to build our prototypes, including several Microsoft Cognitive Services and the Azure bot service. All of them are part of the Microsoft AI platform, where you can find services, infrastructure and tools for Machine Learning and Artificial Intelligence you can use for your personal or business projects.

we used only some of the services of the AI platform

BlackForest Hackathon

The BlackForest Hackathon has been the first hackathon ever for our team and we have been quite excited to participate.

The theme proposed by the organizers of the hackathon was “your personal digital assistant”, and after some time brainstorming we came up with the idea of creating an intelligent bot, which assists you with creating your learning schedule. Most of us are serious procrastinators (including me :P), so we thought that such a bot can help us stick to our learning schedule and motivate us along the way to the exam.
The features we wanted to implement for our prototype are

• asking the user about his habits (usual breakfast, lunch and dinner time as well as sleep schedule),
• asking the user about his due exams (lecture, date and the amount of time the user wants to learn for the exam) and
• automatic creation of learning appointments, based on the user input, within the users Google calendar.

With the topic of the hackathon in mind we wanted the bot to gather the user input via a dialog as natural as possible.

Billige Plätze in Action

The technology stack

Cem and I have experimented a little bit with the Azure Bot Service before the hackathon, and we thought it to be a perfect match for the task of writing the bot. We also wanted the bot to process natural language and stumbled upon LUIS, a machine learning based service for natural language processing, which can be integrated seamlessly into the bot framework (because it is from Microsoft, too).
Our stack consisted of, as expected, mainly Microsoft technologies. We used

• C#,
• .Net core,
• Visual Studio,
• Azure Bot Service,
• LUIS and
• Azure.

The combination of C#, the bot service and LUIS provided the core functionality of our bot and we were able to deploy it to Azure within one click.

The Azure Bot Service

The Bot Service provides an integrated environment that is purpose-built for bot development, enabling you to build, connect, test, deploy, and manage intelligent bots, all from one place. Bot Service leverages the Bot Builder SDK with support for .NET and Node.js.

Overview of the Bot Service

The bot service consists of the concepts of

• channels, which connect the bot service with a messaging platform of your choice,
• the bot connector, which connects your actual bot code with one or more channels and handles the message exchange between the channels and the bot via
• activity objects.

Dialogs, another core concept, help organize the logic in your bot and manage conversation flow. Dialogs are arranged in a stack, and the top dialog in the stack processes all incoming messages until it is closed or a different dialog is invoked.

General Conversation flow of the Bot Service

By using the bot service we were able to focus on programming the actual conversation with the Bot Builder SDK. To use the bot service you just have to create a new bot in Azure, and connect to the channels of your choice (Telegram worked like a charm) also via the web app.
After creating your bot in Azure you can start coding right away by using a template provided by Visual Studio, you just have to type in your bot credentials in the configuration file and your good to go. Because we didn’t have to worry about where to host the bot and how to set it up we were able to quickly create a series of dialogs (which involved serious copy pasting :P) and test our conversation flow right away by using the botframework emulator, and when we were happy with the results publish the bot on Azure within one click in Visual Studio.
We didn’t have to worry about getting the user input from the messaging platform and integrating natural language understanding into our bot was very easy, because we used Microsoft LUIS. We were seriously impressed by the simplicity of the bot service.

Microsoft LUIS

LUIS is a machine learning-based service to build natural language into apps, bots, and IoT devices.
You can create your own LUIS app on the LUIS website. A LUIS app is basically a language model designed by you, specific for your domain. Your model is composed of utterances, intents and entities, whereas utterances are example phrases users could type into your bot, intents are the users intention you want to extract from the utterance and entities represent relevant information of the utterance, much like variables in a programming language.
An example for an utterance from our bot could be “I write my exam on the 23rd of August 2018”. Based on the utterance, our model is able to extract the intent “ExamDateCreation” as well as the entity “Date” <– 23.08.2018 (for a more detailed explanation, visit the LUIS Documentation). Once you define all your intents and entities needed for your domain in the LUIS web application and provide enough sample utterances, you can test and publish your LUIS app. After publishing you can access your app via a REST API, or in our case through the Azure bot service.

the LUIS web application

LUIS is tightly integrated in the bot service, to integrate our model all we had to do was to add an annotation to a class and extend the prefabricated LuisDialog to get access to our intents and entities.

[Serializable]
[LuisModel("your-application-id", "your-api-key")]
public class ExamSubjectLuisDialog : LuisDialog<object>
{
  [LuisIntent("Klausurfach")]
  private async Task ExamPowerInput(IDialogContext context, IAwaitable<object> result,
  Microsoft.Bot.Builder.Luis.Models.LuisResult luisResult)
        {
        ...
        }
}

Theres nothing else to do to integrate LUIS into your bot. The bot connector service handles the message exchange between your bot code and the LUIS REST API and converts the JSON into C# objects you can directly use. Fun fact: the integration of the google calendar into our bot took us several hours, a lot of nerves and around 300 lines of code, whereas the integration of our LUIS model took around 5 minutes and the lines of code for every LuisDialog we created.

Summary

By using the Azure bot service in combination with a custom LUIS model we were able to create a functional prototype of a conversational bot assisting you in creating your custom learning schedule by adding appointments to your Google calendar in roughly 24 hours, all while being able to understand and process natural language. With the power of the bot service, the bot is available on a number of channels, including Telegram, Slack, Facebook Messenger and Cortana.

It was a real pleasure to use these technologies because they work seamlessly together. Being able to use ready-to-use dialogs for LUIS sped up the development process enormously, as well as being able to deploy the bot on azure within one click out of Visual Studio. I included a little demonstration video of the bot below, because it is no longer in operation.

demo part 2

Zeiss Hackathon Munich

Our second Hackathon we participated in took place in January 2018. It was organized by Zeiss and sponsored by Microsoft.

The theme of this hackathon was VISIONary Ideas wanted, and most of the teams did something with VR/AR. One of the special guests of the hackathon was a teenager with a congenital defect resulting in him to be left with only about 10% of his eye sight. The question asked was “can AI improve his life?”, so we sat down with him and asked him about his daily struggle being almost blind. One problem he faces regularly, and also according to our internet research other blind people, is the withdrawal of cash from an ATM.
So after some time brainstorming we came up with the idea of a simple Android app which guides you through the withdrawal process via auditory guidance. Almost everyone has a smartphone, and the disability support for them is actually pretty good, so a simple app is a pretty good option for a little, accessible life improvement.

We figured out 3 essential things we needed to develop our app:
1. Image Classification, to distinguish between different types of ATM (for our prototype we focused on differentiating ATMs with touch screen and ATMs with buttons on the sides),
2. Optical Character Recognition, to read the text on the screen of the ATM to detect the stage of the withdrawal process the user is in and generate auditory commands via
3. Text to Speech, which comes out of the box in Android.

The Technology Stack

We wanted to develop an Android app, so we used Android in combination with Android Studio. We chose to develop an Android app simply because some of us were familiar with it and I always wanted to do something with Android.

For both the image classification and the OCR we again relied on Microsoft Services.
The Microsoft Vision API provides a REST endpoint for OCR, so we got ourselves a API key and we were ready to go.

For the image classification Microsoft provides the custom vision service, where you can train your own model.

Plugging the parts together

The flow of our app is quite simple, it takes a picture every 5 seconds, converts it into a byte array and first sends it to our custom image classifier to detect the ATM type. After the succesful classification of the ATM all further taken images are sent to the vision API for optical character recognition. We get a JSON as a response with all the text the vision API was able to extract from the image. The app then matches keywords, we focused on the flow of ATMs from Sparkasse, with the extracted text to detect the current stage of the withdrawal process and then create auditory commands via text to speech. We didn’t even have to rely on frameworks by Microsoft like in the first hackathon, all we needed was to call the REST API of the services and process the response.

Summary

Much like in the first hackathon we were really impressed how good the services work out of the box. As you can imagine the images of the ATM were oftentimes pretty shaky, but the OCR worked pretty good nevertheless. And because we only matched important, but distinct, keywords of every stage of the withdrawal process, the app could handle wrongly extracted sentences to a good degree. Our custom image classifier was able to differentiate between ATMs with touch screens and ATMs with buttons pretty reliable with only 18(!) sample pictures.

our custom ATM type classifier

After the 24 hours of coding (-2 hours of sleep :/ ), we had a functioning prototype and were able to pitch our idea to the jury with a “living ATM” played by Danny :).

The jury was impressed by the prototype and our idea of a “analog” pitch (we had no PowerPoint at all) and awarded us the Microsoft price. We all got a brand new Xbox One X, a book from Satya Nadalla and an IoT kit, which was pretty cool (sorry for bragging :P).

Billige Plätze and their new Xboxes

Takeaways

I think there are 3 main points you can take away from this blog post and my experiences with AI as a service.

1. You can create working prototypes in less than 24 hours
2. You don’t have to start from scratch
3. It is not a shame to use finished models. When you need more, there is always time!

Before using these services I thought AI to be very time-consuming and difficult to get right. But we were able to create working prototypes in less than 24 hours! The models provided by Microsoft are very good and you can integrate them seamlessly into your application, be it in your conversational bot or in your Android App.
All projects are available in our GitHub organization, but beware, the code is very dirty, as usual for hackathons!

I hope I was able to inspire you to create your own application using AI services, and take away some of your fears of the whole AI and Machine Learning thing.

Have fun writing your own application and see you in our next blog post!