I’d been to Goto Arhus a couple of times and really liked the conference. So this year I decided to go and check out if Goto Amsterdam was the same high quality. And indeed it was. Great speakers, good content, nice food, all in all an excellent experience despite the (very Dutch) lack of air conditioning on two of the warmest days of the year. Below is my summary of all the sessions I attended. When available I will have the title of the presentation link to the video of the talk.
Everyone is doing agile because everyone else is doing it, not because scientific research shows that it works. Pavlov’s research led to behaviorism, expecting people to respond to rewards. Taylor recognized that for repetitive jobs rewards led to improved performance. Sadly this no longer applies to our work as it is no longer boring and repetitive. But managers still believe this. And it’s not just managers, a lot of us still believe this too. Many of us spend hours staring at a screen trying to solve a problem without taking a break. Taking a break makes us feel guilty.
in 1949 Harry Harlow gave a group of monkeys some puzzles. He noticed that they started on the puzzles before they had gotten a treat. They simply liked doing puzzles. This lead to the concept of intrinsic motivation. When he started rewarding them, they lost interest. This research was ignored for two decades.
Kahneman and Werschky came up with behavioral economics. Where they argued that our decisions are not rational. The experiment used was the ultimatum game. (Split ten dollars, where you both get to keep the experiment money if the offer is accepted.) Fairness counts even with monkeys. (Which was demonstrated with an awesome video clip of two monkeys receiving grapes or cucumber for a certain task.)
Rewarding children with pizza to read, they chose short books and didn’t like reading anymore. All the research shows that extrinsic rewards undermine intrinsic motivation. Dan Ariely found that there is a correlation between the height of the bonus and performance, but that it is a negative one.
So remember bonuses only work if the job is boring and repetitive. Or if the required result is very close to the incentive. Like the mother who paid her kids to fall down a lot while skating. In order to fall down, they had to skate first. You can also turn it around by giving the bonus up front and then let them keep it when they reach the target. We are very averse to loose things. Positive feedback is also a kind of reward. This is not as black and white as other bonuses, but you have to keep in mind that only beginners need a lot of positive feedback, experts on the other hand need a lot of critical feedback.
Neuroscience has proven that the pleasure center (which is triggered by financial rewards) and the area involving cooperation can not be activated at the same time. And pleasure will win out every time!
The best way to create an effective team is to make them feel good about their job. Even rescue dogs who are trained to find living people in the rubble want to feel useful, so if the disaster is really bad, at the end of the day the rescue workers hide, so the dogs can find at least one living person. Most people care about what they do, letting them feel useful is the most powerful motivator there is.
Matteo Manferdini – Education is a game
Angry birds is based on a simple mathematical formula. Of course you’re not going to learn this formula, but you are going to learn a lot about physics, such as force, angle etc. You don’t play games to learn, though, you play them for the fun of it. When they turned some stairs that were located beside an escalator into a piano, 66% more people took the stairs instead of the escalators. You can really entice people to do things by making them fun. [For more info on this subject, read Reality is broken by Jane McGonigal] In games we become the best version of ourselves. The average gamer spends about 10.000 hours playing games by the age of 21. This is both as much time as they spend in school and the amount of time you need to spend to become a master at something.
But what is fun? In the book ‘A theory of fun for game design’ Raph Koster describes a theory which describes the state of flow, which isn’t fun in and of itself, but does help. In order to get there you need a challenging activity that requires some skill, clear goals and feedback. The trick of a good game is to keep players in the flow zone. What makes flow fun is learning something. Learning makes our brain release the chemicals that make us feel good. From chess you can learn about strategy and tactics. From tetris you learn about spatial relations and planning. First person shooters teach you about spatial relations and fast decision taking. All games teach you something. Everything the cavemen needed to survive is hardwired to be fun.
Since fun is learning, games are a part of education. But most educational games are not fun at all. They are like chocolate covered broccoli. Learning should not be the reward, but the mechanics of the game.
Nick Grantham – Are you giving teachers blisters?
Changing from Australia to Ireland was quite hard. It involved a transition in footwear as well. Like footwear we create products that are designed for everyone, or are very specific, or are innovative. But it hurts when they don’t fit. Right now we are shoehorning a lot of technology into the classroom. But often this hurts a lot and gives teachers blisters. We have to pay attention to the fact that teachers have a very different perspective from us coders.
A lot of teams involved are in it for the money, which almost never results in products that are a good fit.
Knack for teachers was an online platform that allows teachers to convey their data (classroom attendance, grades) into nice graphs. But it never really took off. When building it he only got feedback from relatives. They were teachers, but relatives are hardly ever the best people to ask feedback from.
Converse shoes started out selling all kinds of shoes with rubber soles. But when they wanted to branch off into sports shoes, they didn’t take off until they took basketballer Chuck Taylor on board, who gave them a lot of expertise from the field.
You should always take customer feedback over intuition. So you need real feedback from real educators (and not just one or two either). A second piece of advice is to have a cross functional team. You need people with different perspectives. The third piece is to build connections and relationships, which allow you to gather feedback more easily.
When creating products for the educational market, keep in mind that it is very much a global market. But it is also a very slow moving market. Edison predicted in 1922 that moving pictures would revolutionize education, and just look at how long it took before that really made it into the classroom. Another challenge is that you have to get your telling to be valued and integrated. The final challenge is the large amount of different devices, as most schools don’t have the budget to give all students a device, so they have to use their own.
But when you can overcome these challenges, you can change the world! But you must be in it for the right reasons and prepare to be in it for the long game. And you really have to be passionate about learning!
Robert Bor – Putting Java in its place
Java right away tried to be everything for everyone. But it wasn’t so great for the desktop. And applets weren’t so great either. but it promised liberation from C and C++. Microsoft came with J++, which was legally shut down by Sun. Later on they came with C# on .Net. But the main strength of Java was the vibrant community. For simple applications .Net was cheaper as they had a stable stack, whereas Java had a continuously changing stack, meaning we had to rebuild our experience over and over again, leading to higher overhead costs. And so .Net came to rule the world of retail, whereas Java ruled in big corporations. In the beginning of Java there wasn’t much open source tooling available. But then came the move from mainframes to Linux servers and with it the move to open source. During all this, the JVM was a constant. It really is the strongest point of Java.
Then there is the whole concept of enterprise Java. It didn’t work really well, but we coped. Then Rod Johnson came along and gave us Spring. A lot of the good things of Spring were later brought into the enterprise edition of Java.
Another thing that was hard to deal with, was the database, as there is a paradigm mismatch between OO and RDBMS. First we used JDBC, and later ORM. Then we had the JPA. But the JPA had to be bypassed for a lot of things. These days the RDBMS is challenged by a lot of other products.
But on the web side of things Java filled a gap. We’ve seen a lot of frameworks come by over the years. But the more things a framework tries to do, the more trouble you will have with it. And things got even more complicated when the front-end technologies took flight. (HTML5 etc) Many of the functionalities became obsolete then. And where a technology works on the boundaries of it’s usefulness, the more serious competition it will encounter.
From 2007 to 2011 were the uncertain times when Oracle acquired Java. A lot of competitors were claiming the death of Java. And so we tried Ruby on Rails, but it tended to bog down. Then we tried Groovy and Grails, but it was immature. But then Java made a comeback. Both LinkedIn and Twitter moved to Java. And Oracle turned out to be a better steward than expected. And then there was Android, with Java under the hood. Nowadays, we use Java for the back-end and no longer for the front-end. And if this wasn’t enough to kill Java in the browser, there were the security issues. In the end they had to delay Java 8 for it, which dented the credibility. Despite the image, Java in the back-end is still really secure.
So where are we now? The percentage of Java developers is decreasing, but the number of Java programmers is still growing. They couldn’t really back up their claim of universality. Java is not for the desktop, it’s not for use on the browser, and it’s not for rendering to the browser. But the JVM is here to stay and there’s a vibrant community surrounding it.
How we currently develop software: a controller that does something and then redirects to a page, which has some bindings. But this mixes a lot of concerns: querying, transactions, reporting… The data will usually not know how it got to a certain state, this information is lost.
Event sourcing is an alternative to this way of working. It captures all state changes as a sequence of events. This looks different, but banks already use this approach. This is nice, but how do you query it? Our old model is now split into a query model and a command model. But this leads to synching problems on the models. For event sourcing, you store the command model and deduct the query model from it.
Why would we want to do this? For the business: To capture the user intent, for historic information, for storage decoupling, and to defer decisions. For us nerds: tell don’t ask (no more getters and setters), isolated domain tests (you can test on events that are or ate not on the database), debug information, conflict resolution. For example when building new features like a timeline for invoicing, you can make it backwards compatible, as you already have all the data you need.
Besides ease of querying and advantages in implementing business logic, it was also a lot easier to measure feature usage. No BDUF (big design up front) for the data model needed. But it does require a mental model change, and you might still need event updating (as you can’t always get it right the first time), defining events isn’t all that easy (granularity is hard), and it takes more work to do simple stuff. Some of the open challenges are replaying all events, asynchronous view model updates, zero downtime deployments, and scaling.
Erik Meijer – A Monadic Model for Big Data
Data shouldn’t be stored (unless you really need it for historical purposes). A thermometer, for example, is a database with an infinite amount of doubles. Erik’s goal is to get rid of the relational database. Our applications should learn to deal with live data. The only part of ACID you need is the D (durability), you don’t need atomicity as relational databases only need them because you split up the data in an unnatural way. You don’t need relational databases to query either. Clearly a thermometer doesn’t have a database inside it, but you can query it just fine.
Pick the solution that fits you problem!
(As you can see, I didn’t get a whole lot from this presentation as Erik talks really fast, and it’s quite hard to follow the story behind his presentation. So while the talk was definitely entertaining, it wasn’t very educational.)
This keynote actually consisted of two talks. The first one about schemaless databases and the second about the essence and fluency of agile.
What is schemaless? Usually we define the columns by telling what they contain and what type that is. According to most nosql people Schemaless is great as you don’t have to think about what goes into it. But despite this, there is always an implicit schema. So how do you know what it is? Will the field be called zip, zip code, or postcode?
This idea is also present with in-memory models. Most languages also have this idea in dictionaries. Using literal keys in your dictionary is a smell, that indicates you probably want a more rigid schema. Common state vs. variable state. You can even mix these by defining an explicit schema with getters while using a dictionary for the implementation.
So far we’ve looked at the schema as a storage schema. A less common view of schemas is the predicate schema where you allow anything to be stored, and then use predicates to find the objects that fit what you are looking for. This allows you to have several schemas with one storage. This is valuable as it allows for contextual validation. Validation rules often change, based on the context of the action you want to execute. Often you want to store partial information, which needs weak storage validation, while you want to validate them more strictly later on.
When would you use this?
Implicit schemas ate usually a bad idea, as you will have to look through a lot of code to find out what the schema is. However in cases where the data isn’t uniform, an explicit schema is too hard. Usually you find this when you have a lot of custom fields or a lot of non-uniform types such as in event logging. A second case is for schema migration, but this is something you have tho be really careful with. Explicit schemas are often not as hard to migrate as you’d think.
Agile: essence and fluency
This talk is based on the research by Diana Larsen and James Shore [See the original article] in the 1990′s the idea tho solve problem in development was plan-driven processes. However a lot of people felt that this was not the answer, and the agile movement started. Plan driven depends on requirements being stable, however this is never the case, so they tried to ban the changes. The people driven agile word instead embraced the change. Their plans change a lot. However adaptive planning is quite hard. But changing from process first to people first is even harder! Usually we have a bunch of processes and a group of people and we divide the purple over the process slots. But in agile we look at the people first, and let them form their own process according to what works for them. (So don’t force your team to work in some defined agile way! They have to decide what works for them.) This does mean that not all teams are equally far progressed in their transition to working agile. To give a bit of an idea of how far along a team is, Diana and James created a scale. Mind you that this scale is very loose, you can’t really accurately measure teams on it! They called their scale agile fluency and used stars to indicate the fluency a team has.
1 star: adaptive planning is starting to kick in, the work is divided into small chunks. To get here you need to invest in team development and process design. This typically takes a few months and most teams reach this point, but also stay here.
2 stars: this takes an agile take on technical things. This requires an investment in technical skills, and typically takes up to a few years to reach. This is a lot harder to reach.
3 stars: at this level the team becomes much more active in deciding what to build. This requires much more investment, as it requires incorporating the business values in the team. This usually takes a few years to reach. Very few teams reach this point as the organizing itself often isn’t ready.
4 stars: only seen in very small organizations, almost hypothetical.
Linda Rising – The agile mindset
You’re never too old to do anything! (Or too ‘anything’ to stop you when your heart is set on it.) But most people don’t know this. They have a fixed mindset and believe that they can’t change their intelligence and other talents. Therefor they will never try to be more than they think they are, and limit themselves. Other people know that intelligence and any other talent can be improved by trying harder and putting in more effort. Just as you can train your muscles to become better at sports. Which of those two mindsets you have is determined at an early age, mostly by what people around you tell you. This was proven by a scientific experiment among students.
A group of students got an easy test, then the group was split into two groups, with one group being given the fixed mindset, and the other the effort mindset. Then the researchers asked the students whether they would like a hard test that would allow them to learn things or an easy test. 90% of the effort students chose the hard test. 80% of the fixed students chose the easy test. Then they all got a hard test, regardless of what they had asked for. Effort students enjoyed it, but fixed students struggled. In phase 4 they got to choose between seeing the exams of those who did better or those who did worse. Effort students chose the former and fixed students chose the latter. In the next phase they got an easy test again. The results were remarkable, effort students had improved, but fixed students had actually gotten worse! All students now got to give advice to new students. Effort students gave advice and encouragement. Fixed students gave warnings and lied about their results.
The only difference between these groups came from telling one group that they had done well and that they must be very smart. The other group was told that they had done well and must have worked very hard. That was the only difference, and as small as it is, it caused the first group to fall into the fixed mindset and the second group to fall into the effort mindset.
The effort mindset can also be called the agile mindset.
Now when we look at why there are so few women in IT, we might want to look at the difference between little girls and little boys and how we raise them. Most bright little girls are told that they are perfect. They have good communication skills and know early on what the world wants from them, and act accordingly. They have a fixed mindset and as soon as they encounter a hard test or course they give up and move away from it. Bright little boys don’t have as good communication skills and it takes them a lot longer to figure out what the world wants from them, so they are told from the beginning that they are not perfect and should try harder. This leads to a very agile mindset.
These mindsets can even be found in company culture, Enron had a very fixed mindset, where the best talents were hired and the top ten percent at the bottom are fired. Southwest Airlines has an agile mindset and hire people for their attitude and then teaches them to become better.
Simon Brown – Sustainable competence
[Author of Software architecture for developers]
When left to themselves, most teams do what they’ve always done, which is usually some form of waterfall. DSDM Atern is a great starting points for teams that have never done agile. One team started using it, but still wrote a big requirements document. Then they did a workshop on how to work with the tool and created a prioritized list of requirements. Then the evangelist went on holiday, the list was dropped and the big document revived. Then the entire tool was dropped. One year later they still hadn’t released their software. Under pressure people revert to the old ways. Most project managers do not have a technical background, and merely harass the team by putting them under pressure. Status reports often don’t reflect reality, and failure only becomes visible at the end. And despite the name, common sense isn’t as common as everyone thinks. [See also: The Project Manager's Little Book of Common Sense - ebook by Kirstie Brown] Agile assumes that all people will do their best and that you should trust them. However in many companies the employees play Project poker: where competing teams are bluffing about making deadlines to see who will drop their cards first.
Isn’t the answer you’re looking for. Modern software development practices are not optional! But when asked “Have you read books by…?”, a lot of people have never heard of the great names in our industry and aren’t willing to learn apparently. Outsourcing and offshoring complicates things even more, by adding cultural differences and distance to the mix. Not to mention the fact that outsourcing needs to be settled with contracts, and contracts contain no information whatsoever about the product that is being built. So now everybody is assuming they’re talking about the same thing, which is a sure way to failure.
It’s all about the people stupid! But why don’t we learn? If we blindly do the same thing over and over again, we don’t improve. So how do we get teams to learn? We need to find out their motivations. Any approach will work with good people. Every team should have a master builder (i.e. an architect). This is a role and can be filled by one person or the entire team. And the style of leadership you need depends on which kind of team you have.
Keep calm and take a step back. In a time of stress and problems, take five minutes to figure out where you are and how you want to get to somewhere better.
Kai Gilb – How to Focus Agile so it delivers Value to your Stakeholders
We do projects to deliver value, so everything we do should be delivering value. Value should be central. Agile and Scrum are a step in the right direction, but they don’t put enough emphasis on value yet. Bring is a mailing company in Norway, they bought up all kinds of mailing companies and then wanted to build a web portal to provide all their services to their customers. They used Scrum and did everything right, but sales were down dramatically.
When identifying stakeholders, you should keep in mind that you will have more than just the users. Edison didn’t invent the light bulb, but he made it good enough to be valuable (it lasted longer and burnt brighter). You should find out and quantify what the values are. Then you should evaluate which solutions best generate these values. After decomposing these solutions into smaller blocks, picking the piece that will deliver the most value and developing it, we then deliver it to the customer. But this doesn’t have to be working code, sometimes it can be a change in process for the customer. Then we measure how much value we actually delivered and learn from what we’ve done. Scrum only helps us for part of this cycle.
For every potential solution, for example different kinds of fruit, you can determine some values, like taste and shelf life, and then look at how much value they bring you. These solutions should fulfill a stakeholder value, which in turn should fulfill a business goal. This is not a linear process, but goes back and forth.
For Bring, sales were impacted, because services were hard to find. So they set out to determine how fast the services could be found (which they didn’t know). Then they decided what the goal was, and then they could set out to do everything to improve the speed of finding services. Of course the business doesn’t know how to improve this, so the developers were asked to come up with solutions to increase the speed. After coming up with these solutions they were making estimates about how much faster the site would be when the solution was implemented. One possible solution was to teach the content providers how to make their pages easier to find (i.e. no code needed). Another solution was to build in a filter to limit the results when trying to find a service. Then they measured how long it took the customer to find the service after the change. The next step was to get rid of duplicate services. If you keep doing this you will just wipe out the competition, as your product will be the most valuable in the industry.
Stakeholder values are detached from the product. Whether you have a website or not, people will still want to send packages, for example. Finding services fast is a solution to the stakeholder value of generating more sales.
In another project, a programmer was given the task to implement a CRM, but instead of doing as he was told, the developer went to the CTO to find out what the actual problem was. Turns out they lost a lot of sales due to expirations, which they only found out about at the end of the year. With this knowledge he implemented the CRM and got a satisfied customer.
Victor Grgic – Legacy or not, must keep delivering value (changed just before the presentation to: Legacy is sexy)
Let’s remove generic, reusable and flexible from our dictionary!
Many projects today are in place to replace old technology with a newer one. But this is not such a good idea.
Most buildings in the world these days are made from mud. The great mosque of Djenne has beams sticking out so the local population can cover it in a new layer of mud each year. It is a beautiful building and a living system. As soon as you try to tear down old systems and merely build a new one to replace it, it will never become living software.
In the port of Rotterdam they had two goals: replace the old system, and support the expansion of the port. The first attempt has hundreds of use cases and lots of documents, etc. The first use case took six months and then still wasn’t finished. So they restarted the project. This time they used agile processes and delivered value within one or two sprints. Welcome to double legacy, as there are now two systems to maintain. Legacy is really something you want, because if you don’t have software in production, something is wrong.
Which path to choose, which part should be replaced first, how do we prevent a big bang, where to start? The answer for the port was to follow the ships through the harbor.
Migration by strangulation (moving functionality piece by piece). Business events shouldn’t change a lot unless the way the business works changes. So if your events change a lot, you probably chose the wrong ones. You should make sure that each business event done by the user propagates between the systems (that is, if it is entered in the new system, the old system should know about it and vice versa).
In nearly all cases it was unknown whether a component would be reused, so it didn’t make sense to make it generic, and these words were banned on every level in the project. In order to prevent creating a mess, the first team built the simplest possible solution and the teams following it up created a new even simpler version. Then they got together to talk about it.
Contrary to what James Coplien says it’s possible to work with a partial domain model, as long as you refactor it when needed. You have to strive to choose solutions that are easy to replace, and if that’s not possible, you have to think about it really carefully! Preferably with as many people as possible.
Mike Lee – The app universe after the big bang
In the beginning, like five years ago… The Obama 08 app was wildly popular, yet the 12 app was mostly ignored. The golden age is over, but this means you can make a lot of money, as everyone needs an app. We’re now in the silver age, this means there is money in it, but it’s boring, and we’re all dreaming of being an artist. You still can, but you have to be the smartest, as art is hard. Rembrand van Rijn is the greatest Dutch artist, because he knew how to make money with it. But we have to pay attention, as earning money involves knowing about marketing and pricing. Both of which we’re not very good at it. (See jury.me for a 5-part series on pricing.) We also need to worry about budgeting. And be honest about it, don’t think you can live on crackers. At the 3-month burn you can give up your job, at the 12-month burn you can go and work on your own stuff. (A 1-month burn is the point where you have enough money to pay all your current bills for one month.)
You need to hustle, you need business cards and an elevator pitch, you also need to wear a shirt with your own product and not somebody else’s product. You need to respect marketeers, as they’ve got skills you don’t, and you’ll need them at some point.
How to fail? Come up with a bad idea, it will kill your dreams. Don’t do ‘its like x with/for x’. So make sure to come up with original ideas. Don’t make games!!! Games are the opposite of good software. You need to solve boring problems that nobody else wants to solve, as this is where you can make money. Games don’t have a value proposition, and a lot of competition. There are more than 200 games uploaded every day, people won’t even notice your app. Boring problems have a nicely narrow domain scope, whereas games have an immense scope, which will cause you a lot of headaches.
Is this art? Get over yourself! If you can make that boring problem into a wonderful and easy to use app, you can make tons of money.
Engineering is hard, because humans are confusing, and perfection is unachievable. Engineering is about compromises. Work is unavoidable. If you try to make someone else do it, you will fail. Feel free to ask for help, but don’t make someone else do all the work. Coding is expensive, as it takes a lot of time. Art Is only produced through suffering and sacrifice. You will kill babies, hopefully metaphorical ones. And you will loose friends, either because you will kill their babies or because you don’t have time to see them. You will be disappointed, as it will hardly ever be like you imagine it. You will need help! So we’re lucky to live here in Amsterdam with one of the biggest communities in the world.
Chemistry is a game about science. At first it was about cute lemurs, and nobody cared. After talking to everybody who hadn’t been consulted for the first round, the lemurs were replaced by atoms. And that’s what it took to make it fun, even though it isn’t successful as of yet.
Liferay Portal 6.2 has just been released. One of it’s interesting new features are Application display templates (ADT), that promise to allow easy and flexible rendering of content, without changing JSP’s. It’s implementation gives me some security concerns for all users of Liferay. Read more…
Did you ever needed to have a group of option in which just one item could be selected, but the user did need to have the option to deselect any chosen option in HTML?
It can’t be done just by HTML checkboxes or radio buttons and the user experience of a select with options isn’t sufficient.
We did have to provide such a solution in a recent project.
Have you ever tried to change something? In (part of) an organisation, or maybe in yourself? How successful was it? How did you accomplish this feat?
According to this great little book called Switch, you most probably have addressed three significant areas: the rationale, the emotion, and the environment. The authors Dan and Chip Heath call these: the Rider, the Elephant, and the Path.
Just as last year, I joined Agile Coach Camp in Vierhouten. A weekend full of exchanging ideas with some of the most inspirational Agile Coaches of the Netherlands and beyond. It’s an energizing weekend full of questions, discussions, games and good company, where you can learn all the skills and techniques a good agile coach should know. The first evening is always relaxed, with people creating their own badges, enjoying dinner together, introducing themselves and their passions, and staying up way later than is reasonable on a first night of a busy weekend.
This is a trip report about my visit to Devoxx UK, where I was both a speaker and an attendee. Throughout this report you’ll see quite a few links. When the link is a name, it will point to a Twitter account. When the link is a session, it will point to the slides on Parleys. As the content is being published, videos will also appear, so you might want to bookmark the sessions on Parleys that you’re really interested in. (Or keep a close eye on the Parleys Twitter account.)
For me the first ever Devoxx UK experience started with a meet and greet on Monday, followed by the speakers dinner. Being rather tired, Regina ten Bruggencate and I decided not to go back to the meet and greet after dinner and headed to our hotel instead.
The next morning we met up at the conference and were somewhat disappointed by the fact that there was no breakfast. Fortunately, I had already had breakfast, so some tea and a cookie were more than enough for me. Read more…
Although, many software packages claim to be perfect and bug free, the real world turns out to be different. Therefore, most software undergoes maintenance and will get better with respect to bugs and and (new) features by releasing newer software versions. Mostly it is avoided to break any compatibility with the older version to ease pains of migration for the users, or they provide clear and well described steps to migrate the software either manually or automatically. However, sometimes it is necessary to break some part of an API in order to significantly improve the software.