WeAreDevelopers 2019 Berlin – The Good and the Bad parts

Reading Time: 7 minutes

You can find my expectations here. And here are my actual impressions:

Arrival

The conference took place on the 6th and 7th of June at the CityCube in Berlin. The CityCube is an exhibition site which is located roughly 10km from Berlin centre. My hotel was in Berlin-Charlottenburg, which is a nice area located just 2 stations from the exhibition site.

I arrived late on the 5th of June. Having not really planned my attendance I wanted to check the usual suspects (eg the web page) for more information. But wait. There is an app for that right? And there was. After downloading the app from the Appstore, I quickly set up an account and was ready to take a look. Overall the app was solid (with some bugs or undesired features; later more on that). I found the activity stream pretty useful. The activity stream is like a chatroom where attendees can exchange thoughts. After reading a little bit, I was able to gather most of the important info and got a little bit hyped by the people in the room. There was also an agenda section in the app which I could browse either by date and time or speakers. Each talk or workshop had a brief description. Each talk could also be added to a favourites section which was nice. In that way, I gathered rather quick my favourites and after going through them again by time and eliminating the less interesting ones I was ready for the first day.

Pro-Tip 1: A calendar or timeline section in the app where one could view one’s favourites would be nice. In that way, intersecting talks could be easily spotted.

Day 1

I arrived a little bit early at the venue because in the chatroom there were also some concerns about long queues. The weather was really nice, so I was not really worried to wait a little bit. But the fear of waiting for hours was not justified. There was enough stuff to take care of the attendees. I waited maybe 10 minutes. So all good.

Once I arrived at the main stage I also realized that there was more than enough space to accommodate everyone. With my schedule it went from here like this (Some of the talks I attended):

Welcome by WeAreDevelopers

The usual greetings and organizational stuff. It didn’t take so long so it was okayish. But already here I realized that the sound was really bad. Sitting somewhat in the middle you would get an echo. And that was without any other talks being held in parallel.

Pro-Tip 2: Please test the venues sound properties beforehand and adjust accordingly.

Where Machine Intelligence Ends and Human Creativity Begins – Garry Kasparov

As a starter, this talk was really good. Garry Kasparov is really a charismatic person. The main claim of Garry Kasparov is that eventually a huge amount of (non-creative) work will be replaced by AI. And there is nothing that we can do about it. His conclusion was that it doesn’t have to be a bad thing. We will have more time to do more important stuff.

Business vs Agile – Crimes against development teams continuously committed by management – Gerta Sheganaku

This one I chose based on the title. I was hoping for some entertaining session, actually against management (Sorry I’m a dev). The thing which I’ve got from the talk is that agile works best with top devs in an organization. For this group productivity and “happiness” increases. With diminishing skill set of the devs involved the gains of agile decreases and are even counterproductive in case of devs with decreasing skill set (I do not know how the skill set of devs was measured here and the productivity output either; it’s a company offering, so they have probably some empirical data on this). The fun story was that one consulted company consulted by this company fired almost all stuff based to rehire again for agile.

Lunch

Lunch was an epic disaster. Honestly, I thought lunch was included in the ticket price. It was not. There were around 5 food trucks with different types of food. So this was ok. The problem was that the capacity was way too low. You had to wait like 1 hour in full shining sun to get your food. After waiting for about 15 mins. I decided to go somewhere else to get some food. Doing so I discovered that the part of the CityCube the conference was held in was about 15 min away from the nearest restaurants. Ok, that’s another minus. (PS There was a massive rant about this in the app. Even some invited companies jumped in to deliver some food and free water. Shame, shame, shame…)

Pro-Tip 3: You know how many people will attend. Throughput of the trucks should also be known. Calculate with the worst case.

The Quake Postmortem: The End of the Original Id – John Romero

Yes, this John Romero. The talk was about people, growth, success and the price paid. Romero pictured a small company which was overwhelmed by its “astonishing” success. In the beginning, there is a passion but with success there comes the appetite for larger games and one have to scale. In the end, it’s not about fun anymore. Delivering is what counts. This reflects on the team.

Flutter – Google’s latest innovation for mobile, web, and desktop apps

It was nice. But we have SwiftUI now. Thank you.

Pro-Tip 4: When designing the app, please think about people on a mobile data plan. Scale down pictures posted in the chat (I had like 400MB data usage by the end of the day). 

Day 2

Once in my hotel room I quickly set up my schedule for the last day (Here some of it):

Thoughts on the Future of Programmable Money – Andreas M. Antonopoulos

This talk was epic. Andreas drew a coherent picture of what is wrong with the mindset of closed ecosystems. Starting with castle walls and getting to modern times firewalls was a nice analogy to draw. Eventually we “outgrew” castle walls/castles. Will we be able to break out of closed systems? Andreas has no doubt about it.

25 Years of PHP – Rasmus Lerdorf

I’m not a PHP dev but I wanted to hear the inventor of PHP talk about this un-opinionated language. So Mr Lerdorf is a nice, near to the ground guy. He explained very well that PHP was developed out of necessity. The desire to have a “simple layer” over CGI/C to write programs faster and more readable.

2nd day the lunch situation didn’t really change. There were water and free beer though.

Conclusion

I’m pretty undecided if I would visit this conference again. The speakers were really great but the organisation was seriously lacking.

Was there something good in waterfall that lacks in agile – DDD

Reading Time: 9 minutes

There is just one part, one piece step/phase of both methodologies agile and waterfall in which the old fashion way, thinking of one aspect, has some advantage over the new one agile. This does not have to mean that agile (scrum) is bad and developing projects by this methodology are doomed to fail and all other projects managed by waterfall will have great success. The idea of this blog will be to motivate managers and others to think a little bit more out of the box, instead of blindly implementing and using everything from the books what is new. Before we start to talk about whether something is missing or not in agile let’s first introduce basics of both methodologies.

Agile way

These days every software developer knows the basics of agile which are given in the agile manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:


Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan


That is, while there is value in the items on the right, we value the items on the left more.

https://agilemanifesto.org/

These thoughts are maybe more abstract, but looking more from real life experience we can define twelve principles:

  1. Customer satisfaction by early and continuous delivery of valuable software
  2. Welcome changing requirements, even late in development
  3. Deliver working software frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the primary measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Best architectures, requirements, and designs emerge from self-organizing teams
  12. Regularly, the team reflects on how to become more effective and adjusts accordingly

This is a theory what should some agile methodology have. And again there are no strict phases that one project has to go through during its lifecycle.

The most used methodology that is based on agile is scrum, so we are going to talk about it. It is a methodology which implements the principles of agile. Because it is a real practical process of developing some software it has strictly defined processes of how the software should be developed.

The project should be done in a series of iterative small steps which are called sprints. One sprint should have a maximum period of one month. Most common is two weeks. Following pictures shows how scrum phases and sprints look like:

What can we focus on from all of this? The main goal in Scrum – Agile is to develop incrementally. Always split all requirements on smaller ones and work on a few of them every sprint. The idea is to make small requirements so that several can fit and can be done in one sprint. After every sprint, there will be a release and will be presented to the PO for review (features bugs etc).

Waterfall way

Many of the older generations may have been working on some projects organized in this way and they know and are familiar with the main differences compared with agile. But for all others, we will try to explain it in few words.

Basic model flow for the waterfall has following stages:

  1. Software Requirements
  2. Analysis
  3. System Design
  4. Coding and Implementation
  5. Testing and Verification
  6. Operation and Maintenance

And we can see few diagrams and models how waterfall looks like:

Here we can see that nothing is repeatable and everything is strictly defined. When the project starts, it has to go through every stage and every stage has to be confirmed that is correctly done. But what means no repeatable. It means that in all of these phases should be covered all scenarios that have to be implemented and are planned for the project.

Or more detailed explanation, when the analysing of the requirements starts, it will be for all requirements that should be in the project. It can take maybe one month or more. It can not be done with just a few meetings between the clients and business analysts, because in this phase all requirements should be defined in detail.

After both sides agree that requirements/business scenarios defined in these stages are good and are everything that will be done, the next stage, the design will start. In some ways, this is the stage when real implementation starts. Architects and designers are analysing all the requirements, written in the first stage, and with that information and knowledge, they will start to design the model and set up the application (technologies and frameworks which will be used).

Next step will be implementing all requirements. The process with development and testing of every requirement after it is done. In the same phase, bugs will be fixed along with everything else.

After all requirements are done and tested, the project goes in the final phase which will be the deadline when the project has to go live – production.

Right way of implementing Agile

Comparing these two ways of managing/doing one project we can agree that agile is much better and more reliable to be used instead of waterfall. We don’t have to wait a long period to be sure that we are doing what is right and if it will be accepted from the clients. Acceptance of the project is with every iteration.

Why is this more and more adopted from companies that develop different applications, small and big? It is because they can be sure that everything that they are going to do this month will be accepted. If it is not they are going to lose the effort only for that month. Not the effort and work for one year like in waterfall.

Starting from this point companies are forcing to have something from the start. Don’t like to spend time on analyzing and defining the whole data domain, taking in advance all requirements and setting up the whole architecture by the real needs of the project. That will cost them time and money.

Everything will start great. All stories, epics will be defined after the projects start. Split them in small requirements which can be done during one sprint, they will be defined during the sprints or few sprints before they have to be done. There will be no useless work and effort.

The data model will be defined and created with every new requirement, with every new feature or maybe some bug. At the beginning that data model will serve very well. Requirements can be done fast because there will be no issue of creating a new entity and reference it to some existing one. DDD will be fulfilled while we solve every ticket. First, define the data then implement the code.

But this will be done only for the small parts of the data model and of the project. There will be no defining big data domain that will be useful for the features that will come next. For a week, month or year.

After some time and set up some data model, with every new ticket that will require model changing we will have more and more difficulties to adapt existing data model for the new requirements. In one moment we will have to do bigger changes in the model. The main reason for this is that when we implemented the requirements we cared only for the needs that we had in the sprint when we worked on the previous ticket, story etc and we were not aware of the needs of the model for the featured requirements.

Then we will have let’s say two solutions:

  • To continue to try to work on the model that we made it by now. Which will make implementing our new changes harder, and with that more time-consuming.
  • Or at one moment stop with new features and spend time on a big refactor of the data model. Which will take a long time without doing anything productive on the project with new features, just refactoring.

In both scenarios we will have less productivity then we had before and less than we expected.

If we make a retrospective what we have done, we will see that we save time at the beginning on analyzing and defining the whole data model but after some time, year or more, we will spend the same or maybe more time on dealing with the bad data model or big data refactoring.

These possible issues that we can have in future, with forcing fully agile from the very start, can be easily avoided if we add one more phase before implementing requirements. Just spend time on analyzing, defining and modelling of the main big crucial epic stories that we have to cover with our project. Which is more like DDD in the waterfall methodology.

Beyond the evolution of agility

Reading Time: 9 minutes

Hey you! In the following article, I try to dare a hypothetical outlook on future constellations of people in the context of entrepreneurial and individual interests.

Currently, especially in the IT sector, the concept of agility and associated methods and artefacts should be widely known, recognized and used. But the question arises for me, after the “naturally even better” solution from the point of view of all participants. Because do we not strive for a world in which we should at least not carry any organizationally open questions with us? Obviously, I do it. In short, you could also speak of a supposed cost reduction and efficiency increase in the entrepreneurial sense. Stop, that was maybe too fast.🤔
Before we venture into the world of free pluralism, it is worth describing the title of the blog to better understand the approach of the coming end of the mentioned agility.

Evolution describes in a biological sense the phylogenetic evolution from lower to higher forms of the living. No matter what exactly the living thing means for us today. However, you can use this progressive development of certain contexts insofar as they represent the nature of our social behaviour or cooperation.
If we now move into the realm of the world of work, here too we can see an evolution in the interaction between the employee and the entrepreneur. Historically, and also in terms of civilization, one can point out the following timeline: of a hunter making his spear in the sense of the struggle for survival for himself and his clan and passing on this skill to the next generation (as a transfer of knowledge or covert order to continue this); about the very first entrepreneurial forms in an ambivalent employment relationship, to actual profit-making production and proven profit-seeking.

Taking into account the number of people and the needs such as food, some can detect a strong delineation of the opportune sides over time. Looking at our modern development, we came from a partly dictatorial working world to a moderately structured hierarchy, into a flimsy open working culture of cooperation. The move, from the largely totalitarian work systems to a self-determining working method, was logical and not surprisingly the first to be found in areas that were difficult to understand and predictable and still are.
The IT 🙄 and development departments were among the first to use well-known industrial artefacts like Kanban in their favour. Over the past few years, this has become a discipline of its own, which in turn has created a responsibility or even a hierarchy. Someone could say, considering the commonly used agile model that necessarily, with control and control mechanisms (Scrum Master, Plannings, Charts, etc.), the claim of self-determination was forced back into a corset.
Everything now has flown over, you can perhaps consider a “return” of things. Somehow, the conflict between the nature of life and the artificial world seems to lead back to the origin. But humanity has and will resist it again and again in this age of the earth.

I do not want to talk about facts, but at least in the area of IT, a closed transition to this form of “things” is almost inevitable. Similarly, there is almost a certain social compulsion to join this. This change can be seen simply in the number of companies that already use agile methods in subareas or their organization. And there are more and more.

But the question of whether it is the absolutely definitive way is only discussed obscure. To publicly confront oneself with a potentially critical attitude is now considered unfashionable and unattractive. It is now a domain of the younger culture to want to deliver themselves to a self-reflective surface. Sometimes one tries to get rid of the already mentioned corset again. Interdisciplinary is the keyword here. But is not that also an escape forward or even back to the past? There has always been a claim to position employees self-sufficiently in the right place in the company. Incidentally, here is a small digression to the “Peter Principle” quite amusing. But I want to concentrate more on the group dynamic aspect.

The dilemma.
As with any innovation, its manifestation and burgeoning acceptance, so to speak creates a generational conflict. If the current protagonists of this culture are, almost without exception, supporters and optimizers of this agile system, there will be a radical discourse for a new kind of corporate structure in the future as well. When? Soon! Relative to our desire to make our participation in the entrepreneurial activity completely uniform and decisive. Because that’s where single individuals try to take the majority to lived self-determination. Then at least e.g. almost every meeting would have a really measurable result. 🤭

Does that automatically include a forced change? I think you have to use the needs and their changing meaning for humans. After all, it was all about survival at first, but in the future, it’s all about not drowning in the mush of the growing mass of potential workers. Prince Lev Nikolayevich Myshkin could certainly be used as a paradigm for a playful and beneficial naivety and, so to speak, a relaxed attitude to life, but so much smart serenity is generally unlikely to be expected. And you and I are full of aspiring ambitions!

Accordingly, the need for a seamless lifestyle that unites both the private and the business. This now applies tangible and more manageable for us. In order to achieve this, thinking and acting must be equated strategically and tactically with an entrepreneur. The modulation of these two life parallels requires a revolutionary act. The employee of today already carries the seed in itself. Not only the claim to shape his working environment according to his needs becomes clearer, no, also the desire for the determinability of his own work, at every convenient time. Hierarchies of today will disappear (the so-called flat hierarchies seem to serve me rather as bread and circuses instrument).
The top and the bottom will remain at a logical level. It is about the personal benefit and the equal distribution of personal claim (profit) in its existing phase of life. Certainly, the fight of transition to such a new system will not be easy, because man is often a little narcissist and the envy in the way preventing. The “New” need reliable friends!

It will again lead to the formation of a new social order, which, however, does not, as it once did, take its impetus from individuals, but represents participation in a global cultural process. Of course, this is more than worrying, but you probably will not even notice, because you’ve always been involved in a change process: Evolution.

So far, all of it has been pretty daring theory and you can also give up irony or cynicism 🤫 here if you have a sense of humour. However, it would be totally overstated to see a reissue of a “labour power” or a dissolution of any democratic aspect. It will simply be the next evolutionary step. There are branches that will eventually cease to exist. But in best case, a new one could emerge before this end.

How could this be in the distant future?
Any demand-driven venture will be reduced to a few but stable organizations. There will only be more or fewer entrepreneurs. Ensuring production and service will be the driving force for all. Each participant joins according to his abilities but is paid in equal parts. There will be no more reward in its monetary form. The remuneration is rather the assurance and availability of other services. Here, not the weakest link determines the beat, as it is e.g. for some scrum teams today, but the sole urgency and benefit to the common good. It automatically uses the right and necessary resources. The self-determined freedom seems to be more than tempting, but now everyone can suffer an entrepreneurial defeat. The motives to succeed are a true basic need. No safety-net but many new opportunities and potentials to enrich his life through his contribution to the community.

In the end, I want to sprinkle a lot of positive energy over the whole thing.
After all, so-called agility has actually given us more courage and freedom in thinking. It is the key to opening the door that will lead us into a new era. The question of whether this article will now have a direct benefit, I would deny. It is also unlikely that a current entrepreneur will engage in radical new concepts in the short term. The dangers for the company and also the social responsibility are simply too big. Also, I can imagine a momentary separation of powers and equal distribution of the consideration, very difficult. Too many dependencies, even in a small artificial trial environment, determine our actions. 🙋‍♂️ But …

It is important for me to offer both the employee and the entrepreneur a world full of new perspectives and exciting opportunities. It may be that I have dealt with this topic too superficially, but I would be happy to receive more opinions and ideas from you. Only those who do not completely ignore the suggestive future will most likely remain successful. In this sense…

stay agile!