Ever visit an event on your own and tried to blend in with the wall, sweaty hands wrapped tightly around your cell phone, internal debating if you just should take a run for the door? Simultaneously hoping to meet new people and dreading someone could talk to you… Well, that’s me!

Let’s start at the beginning

Hi there! I’m Mirjam. I’m a self taught programmer, working as a Frontend Engineer since 2 years. I love to get to know other people in a similar field and learn from them – by hearing about their experience, talking about different approaches to problems and discussing about the best way to write tests.

The thing is: I’m an introvert type of person and I can be really socially awkward at times, so I’m stressed even thinking about talking to new people. Also, I don’t feel comfortable in unknown and new situations on my own. Happily I was always able to find friends to accompany me to user groups. Conferences were a different matter though. I struggled for quite some time with this problem before I realised: I couldn’t be the only one, right?

Conference Buddy

An idea was born! I wanted to create something to help solve my own problem. I wanted to be able to find a “Conference Buddy”. Someone who goes to a conference with me, is a moral support and lets me hide behind them for a bit if needed.

Against my first impulse, I tried not do plan anything further. Inspired by modern product development frameworks like Lean Startup or how Spotify builds products I wanted to take one step at a time.

I built a simple website where I described in a few words what problem Conference Buddy wanted to solve. I added a sign up for a mailing list, created a twitter account and shared my idea with the world. I wanted to see: Are there people like me where Conference Buddy could be of use? Is there a need beside my own?

And on May, 11th, I launched the website and tweeted about it.

Community Love

The feedback was quite overwhelming. It seemed to hit a nerve in the community. Amazingly, this mere idea evolved and within days. People began to send tweets, offering to be and looking for a Conference Buddy. The first successes were made simply over a few tweets.

Just like this, all ideas of next steps I already had thought of were obsolete. Luckily I hadn’t start building anything. There was no need to build a database of names, events and locations and match things artificial. The community was already taking care of that. For the start, Conference Buddy just needed to provide a place where people can find each other easily and get ideas which conferences to visit.

2018 was a crazy year

Conference Buddy started as an idea only 7 months ago and now people have met each other thanks to it. It’s an ongoing project supported by a growing amount of great people and I’m so curious to see where 2019 will take us!

The best thing is: It helps bringing great communities together to support each other while it’s language-agnostic. Front- or Backend? Doesn’t matter. It doesn’t care what framework you use. The communities that adopted Conference Buddy to be more inclusive are colorful and diverse. That’s what I love most about it!

Good morning, and happy holidays! And if you celebrate it: Merry Christmas! I’m not religious myself, but I still really enjoy this holiday because of the many fond memories I have from my time growing up in The Netherlands and Germany. In The Netherlands, as children, we get our gifts from Sinterklaas on December 5th, so Christmas was always chiefly a time to spend with family, eating delicious meals and listening to or singing carols. Since the “rules” for gift-giving on Christmas in Holland are somewhat fuzzy, my family created their own tradition, which was to gift each other a book. We’d then spend most of the holidays snuggling up by the tree with our books and a hot beverage of choice. In Germany, we lived in a small town just outside Munich, and my most vivid recollections are of the Münchner Christkindlmarkt (Christmas market), specifically the unmistakable scents of Gebrannte Mandeln and Glühwein. (They say that olfactory memory is one of the strongest types of memory, and it’s definitely true for me in this case.)

Aside from delicious food and books and Christmas markets and Glühwein, though, the thing I associate this holiday with the most is the idea of giving back. So when Andreas asked me to write something for this blog, I knew it should be easy, because giving back to the PHP community is something that is on my mind often. Of course, once I finally started writing, it turned out to be harder than I expected, because suddenly I felt this pressure to say something profound. But I’ve kept reminding myself to just write from the heart and stay true to my authentic self. In that spirit, I’ll share a few thoughts; forgive me if I get a bit rambly in places.
Read more

Contributing to our software development community can be done in multiple ways. Through code & documentation for existing projects, by starting new projects to showcase new ideas (Disco anyone?) or by running events like meetups or conferences. Some people or companies decide to contribute in more than one of those areas. Besides contributing to and maintaining open-source projects ourselves, we at bitExpert decided to run a unconference event for the local developer community in the Rhein-Neckar region. This blog post covers some lessons we have learned after organizing the unKonf for 5 years in a row.

But first things first. What is an unconference? Unlike traditional conference formats, an unconference has a self-organizing character, relying on the passion and the responsibility of the attendees. It is up to the attendees to decide which sessions they want to hear or present. Those sessions do not need to be of technical nature or generally focused on IT topics, there’s room for sessions about beekeeping, beer brewing or anything else attendees are interested in. What sets our unKonf apart from other unconferences? From the beginning on we focused on running the event in our office space. This limits the number of attendees to about 80 to 90. Since most of them are friends, the whole atmosphere is very open, relaxed and friendly. Unlike other unconference events we decided to start with a keynote session to inspire attendees and to set the general tone of the unKonf. Over the years we had a great line-up of keynote speakers, e.g. Stefan Koopmanschap, Rafael Dohms, Michelangelo van Dam and Jenny Wong. Every keynote speaker shared some very personal insights with the attendees which also added the positive atmosphere of the unconference.

What is needed to run an unconference? Actually not that much: some (office) space, food & drinks and a little bit of time to organize everything. Start small and let it grow over time, that is the best advice I can give you. In the first year we had probably about 30 external attendees. If there is a decent interest in the event, you can organically grow it over the years. The bigger the event gets, the more time you need to invest into marketing, planning upfront and managing the event. The good thing is, the event is an unconference, by definition it is ok if things are not 100% working like they should. Things can go wrong and will go wrong. People won’t complain, that least that’s our experience.

The downside of a small event is that is hard to attract sponsors. In the first few years bitExpert as a company sponsored everything. We did not charge for tickets as we thought it is way too much of a hassle to do that. We always sold out quickly. In the third year it took less than 7 hours after announcing the event until all the tickets were gone. That’s amazing, right? Well, in the end we had more than 30% percent of cancellations, and roughly 15% no shows. Given we had ordered food & drinks for like 90 people, this was a really, really bad situation. That forced us to turn unKonf into a paid event. I feared that people might not come any more or be mad about this move, but nothing like that happened. We still sell out in a couple days and still no one complains if things do not go as they are planned.

I hope I could give you some ideas on how to run an unconference event. If you want to contribute to our software development community but don’t know how, this might be a way that could work for you. If you need more information or guidance, feel free to reach out to me. And don’t forget to follow the unKonf twitter account so that you get noticed once we have set the date for unKonf 2019 😉

“I did not develop the PHP we know today. Dozens — if not hundreds — of people developed PHP. I was simply the first developer.”

— Rasmus Lerdorf¹

Fifteen years ago, I became aware of the PHP community. I joined it three years prior to that.

Communities don’t make languages; languages make communities

I’m not a very chatty person, and I dislike small talk (not the programming language, the casual conversation kind). So, if I don’t say much to you when we see each other at a conference, don’t be offended. When I’m in Europe and my ear happens to capture the unique sound of an American accent, however, I won’t hesitate to say “hi.” I’ll even strike up a short conversation. You might even call it small talk. “Where are you from? How long are you here? What sites have you visited?”

I recall one time when I was in New York and heard the distinct sound of a Southern accent. It turned out that the speaker lived only twenty miles from me in Georgia.

Our languages bring us together and give us identity. When we have nothing else in common, sharing the same language gives us the only commonality we need, and if we don’t share that, we’ll find a way to communicate in other ways. I’m reminded of the Star Trek: The Next Generation episode “Darmok.” It’s one of my favorite episodes of the series, and in it, Captain Picard must learn to communicate with an alien captain who speaks only in metaphors. He succeeds, they overcome a dangerous beast, and the Federation gains a new ally. How? Because of language.

It is a natural human inclination to live among people who speak the same language, to seek them out and spend time with them. After all, you can understand them, and they can understand you. I’m no sociologist, but I submit to you that language is perhaps the fundamental building block of community. Without a common language — a common means of gaining understanding and expressing ideas — there can be no community. After all, the word community is right there in the word communication.² Community is about language.

In much the same way, programming languages create communities. Programmers seek out support and friendship from those who use the same programming language. We get together. We talk shop. We’ve encountered a lot of the same problems in our work, and we can help each other become better programmers by sharing our experiences.

Which came first, the language or the community?

I imagine this is a difficult question to answer. As I said earlier, I am not a sociologist. I’m also not a linguist, although I do have some background in the study of the English language — my bachelor’s degree is in English literature.

As I stated earlier, language makes a community, but a community needs a common language. This is how languages evolve and become new languages. Historically, cultures that came in constant contact through trading, for example, would develop pidgin languages. Over time, these pidgin languages became creole languages, as parents taught the language to their children as their first language.³ Still, there are languages, such as English, that evolved over time as it borrowed from other languages, and changed according to common usage. It continues to change today.

So, communities require communication. In order to communicate, there must be some kind of language, and if there isn’t, the community will create one, and the language of a community changes over time.

PHP is a language; PHP is a community

PHP is a lot like the English language. It began its life as a utilitarian language, serving a simple purpose: processing forms on a web page. A community grew up around this language, further evolving it and changing it to suit their needs, to aid in communication. After all, a programming language is just another means of communication. The audience may be different — in this case, the language is for communicating with a server, database, and more — but the end goal is the same.

In fact, taking this analogy a bit further, PHP/FI, created by Rasmus Lerdorf, is a bit like Old English, while Andi Gutmans and Zeev Suraski brought about their own Norman conquest of PHP, creating Middle PHP (PHP 3.0). PHP 4 and PHP 5 gave us early modern PHP — Shakespearian PHP, if you will — and what we have now with PHP 7 is the natural progression of PHP into its modern form. PHP has also borrowed from other languages: C, Java, and Perl, among others, have all influenced PHP. The PHP extension API makes it easy to make any C/C++ library available directly from within the PHP language. Moreover, PHP acts as a bridge to many different protocols, facilitating communication between disparate platforms.

This evolution is possible because of two main traits:

1. PHP was designed to evolve
2. The community — not a singular language designer — determines the direction and future of the language

These are not mutually exclusive. The language was designed this way on purpose by the community.

Although the PHP community would not exist without the PHP language, the PHP language — as we now know it — would not exist without the PHP community. PHP the language needs the community, and PHP the community needs the language.

A community of diverse backgrounds

Once upon a time, I wrote a post with the same title as this section heading. The premise was that many PHP programmers I know did not start out with the intention of becoming a programmer. They had an itch, a need to solve a problem, and when they scratched it, they used PHP. PHP has a low barrier to entry. It’s easy to write apps in PHP. It’s easy to solve problems with PHP. Sometimes, this results in awful code being released that gets used and reused and becomes wildly popular, to the dismay and horror of others. Still, as I’ve heard someone credit Rasmus as saying, “Who better to write a data filing program than a file clerk? PHP allows them to do that.”

This is the spirit of PHP. It is a community rich with pragmatism and developers from all kinds of backgrounds with matter-of-fact attitudes. They’ll tell you like it is, no holds barred. But they’re also open and welcoming, eager to help and instruct in the ways of standards and best practices, because, at the end of the day, we just want you to be the best you can be.

Like many communities, the PHP one has undergone many transformations over the years, bringing it to its present and mature form. The community consists of core language developers; extension developers; speakers, bloggers, tweeters, authors, and thought leaders; user group leaders and members; and the myriad of other programmers and problems solvers who had an itch and used PHP to scratch it. Likely, you are a member of this community, too, whether you’ve written only a few lines of PHP to solve a problem or deployed massive PHP applications to thousands of servers.

You see, PHP is our language. It is how we communicate. It is not the only way we communicate — indeed, we speak other languages — but we identify with this language because we identify with the people of this community. This community grew up around this language, and it continues to direct the future of the language as it evolves from version to version. We have a voice and a place here, and we are inclusive. We know what it feels like to have an itch, and we know what it means to scratch it, and there are many here willing to help newcomers of every gender, age, race, creed, and background.

The road goes ever on and on

Fifteen years ago, I became aware of the PHP community. I joined it three years prior to that.

That’s how I began this post. It sounds a bit confusing, but I hope you now see what I mean. When I began using PHP, I became a member of the language’s greater community, whether I knew it or not — and I assure you, I did not know it. I struggled along for almost three years, becoming quite competent in the language, all the while never knowing about the knowledge I could gain and the friendships I could enjoy from others using the same language.

It was thanks to a mailing list post by Chris Shiflett that I now consider myself an active member of the PHP community. While PHPCommunity.org, the subject of that mailing list post, has had varying stages of incarnations and activity, it did exactly what Chris intended — it helped build and grow the community. Perhaps you can point to your own moment that you became aware of the greater PHP community. Perhaps this post is that moment for you.

I can’t pretend to know what the future holds for PHP or how long it will remain one of the world’s most popular web programming languages,⁴ but I do know that if you have tinkered with PHP just a little, or if you earn your living from writing PHP applications, the PHP community needs you. We need your spirit and enthusiasm, your drive to solve problems and scratch itches, and your fresh thoughts and ideas. More importantly, we want your friendship.

Footnotes

1. Yank, K. (2002, May 22). Interview — PHP’s creator, Rasmus Lerdorf. SitePoint. Retrieved December 19, 2018, from https://www.sitepoint.com/phps-creator-rasmus-lerdorf/. Return to footnote 1 source.↑

2. Both community and communication come from the Latin root commūnis, meaning “common” or “public.” Return to footnote 2 source.↑

3. This is not true of all pidgins. Many pidgins fall out of common use and die before they are passed on to a new generation as their first language. Return to footnote 3 source.↑

4. Chan, R. (2018, Oct. 16). The 10 most popular programming languages, according to the “Facebook for programmers.” Business Insider. Retrieved Decemember 19, 2018, from https://www.businessinsider.com/the-10-most-popular-programming-languages-according-to-github-2018-10. Return to footnote 4 source.↑

Dear fellows in tech,
We need to talk about unrepresented groups and a new way of thinking. Let me invite you to come with me a little way on my journey from behind the curtains into the public appearance and why representation matters.

“If we could change ourselves, the tendencies in the world would also change. As a (wo)man changes her/his own nature, so does the attitude of the world change towards her/him. … We need not wait to see what others do.” – Gandhi

It’s time to bring out the light under the bushel.
As a mom of five children without higher education or recognized vocational training, I didn’t fit into the regular recruitment requirements. Despite extensive autodidactic training, there were no matching job offers where I could work from home or nearby my hometown. This led me to some unfortunate job experiences. The gap between expectations on both sides was often too big to continue contracts. This experience resulted in frustration and uncertainty.

But this never stopped me to move forward.

If there is no matching job for me in this world, I need to create it by myself.

Over 25 years, I was working for several employers besides my responsibility of managing a big family. One of my hobbies was doing creative stuff with my computer. The access to the world wide web has opened a new universe to me. Building websites for my own, later for friends until I got asked to do it for a small business why I was forced to register a small business by myself as a side-hustle. After now 13 years doing it that way, I decided this spring to start a full-time business as a trainer and consultant for WordPress.

Making a living from services around an Open-Source system like WordPress means also to give something back. One of my job experiences brought me into the ecosystem as an active contributor. I found my passion while translating WordPress, releasing WordPress with German language packs, managing the content on the German project site and many more. But I also learned about diversity and acceptance. The WordPress community is open to all kind of human expressions. But in public appearance, there are mostly men representing what they are doing. Most decisions are made by men. It’s not their fault – in most cases.

The world isn’t monochrome but its human to follow the usual paths. For decades, young girls have been tricked into behaving bravely and obediently. Contributing and working in STEM seems unreachable for many women.

Despite these findings, or precisely because of them, I use my experiences to encourage other women to unequivocally present and defend their abilities and interests. Over several years, I encourage women to speak up and find their unique voice. However, this usually happened in small discussion groups or in one-to-one situations.

You may ask me, why I didn’t make it more public. Unfortunately, I myself fell into the trap of Imposter Syndrome again. The question, “Who cares what I have to say?” is running around in my head like a ping-pong ball more often than I would like to have it.

In 2018, I finally took the chance to share my personal story how working with WordPress literally saved my life at four different WordCamps in Europe. About how I dealt with chronic illness, divorce, the death of beloved ones, about the ups and downs of having a job and losing a job. My talks were honest and very personal. After each talk, I got phenomenal feedback and admiration for my courage to share such touching stories. It was an eyeopener for me.

For 2019 I’ve committed myself to raise the awareness for more diversity and inclusiveness in Open Source communities and tech companies. Many thanks to Andreas for the opportunity, to share my learnings and future steps here as an inspiration to think about what you can do for a more inclusive world.

What are you waiting for? As Gandhi said, you need to be the change, you want to see. If you want to have more diversity in your surroundings, you need to be your own role model.

Representations matters!

Recently at the office I organized a viewing of Rafael Dohms’ talk on object calisthenics and code quality. The entire dev floor was invited. The talk and its concepts were generally well-received by our PHP devs. Our data analysis lead, however, was quick to point out that “this has been around in other languages for so long. It’s not a new concept. Why can’t we look beyond this?”
It really got me thinking: how inspired are we as a community? We have a huge amount of active user groups, conferences, and other opportunities to learn and share knowledge. There’s a lot of support, mentors aplenty, open source libraries to contribute to. It’s an easy community to fall in love with and, in turn, nestle into. But what happens when we get too comfortable?
Read more

Value Beyond Code

“Personally I would never want to be a member of any group where you either have to wear a hat, or you can’t wear a hat.” – George Carlin

When it comes to tech, it’s easy to fixate on the one aspect so easily associated with said tech – the underlying code that makes an application run. It is terribly easy to think that to work in tech, to matter in tech, you need to actually write code. Digging deep in the trenches of syntax and [fill in your favorite letter]DD, picking up the newest fanciest tools, participating in the latest framework battles. It’s not weird to think this, considering how much discussion there is around that one aspect.

But there are many more aspects that are necessary to thrive in tech than code, represented by different roles beyond software developer. Just as I’m writing this blog post, I find a similar sentiment by Emily Freeman on Twitter:

“Stop using the ability to code as the metric of value as an engineer. Plenty of folks don’t code because they’re experts in something else. Like infrastructure. A thing developers often don’t know much about.

If you don’t want to feel less than, stop doing it to other people.”

The ability to code is valuable in tech – but it shouldn’t be the only metric of value. Much of that required expertise cannot be covered by devs alone.

So if you want to work in tech, but not as a dev adrift in a sea of code? That is absolutely fine, and let me underline why.
Read more

Developers don’t like PHP

According to StackOverflows Developer Survey, 58,4% of all PHP developers would like to move to another Language (https://insights.stackoverflow.com/survey/2018/#technology-most-loved-dreaded-and-wanted-languages).

They show it when they write PHP code, too: There is no other language getting close to PHP when it comes to the usage of words like “crap”, “fuck”, “hate” or “shit”:
https://github.com/Dobiasd/programming-language-subreddits-and-their-choice-of-words

The reasons for this dislike are well documented in online rants, for example in https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/:

• PHP is full of surprises: mysql_real_escape_string, E_ALL
• PHP is inconsistent: strpos, str_rot13
• PHP requires boilerplate: error-checking around C API calls, ===
• PHP is flaky: ==, foreach ($foo as &$bar)

He is right: these APIs are neither predictable, nor consistent, nor concise. Current APIs in other programming languages tend to be a lot better nowadays.

Nevertheless, PHP is still used for 46% (https://webspotter.io/category/platforms) or 79% (https://w3techs.com/technologies/overview/programming_language/all) of all dynamic websites as the server side language of choice.
PHP or the spin-off Hack is the base technology for some of the largest internet sites:

• Facebook
• Yahoo
• Wikipedia
• WordPress
• Slack

PHP is even, being a pure web language, on place number 4 of the GitHub language popularity index (https://octoverse.github.com/projects#languages)

What is going on here? Why do these companies still use PHP? Are they just stuck with a bad technology decision they made in the beginning before they got famous?

Cathedrals and Bazaars

1997, at the international Linux day in Wuerzburg, Eric S Raymond told the story about “The Cathedral and the Bazaar” (http://www.unterstein.net/su/docs/CathBaz.pdf) for the first time.
He describes to major strategies to develop software: the cathedral strategy and the bazaar strategy.

The Cathedral

ESR writes:

In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you’ve winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect

Cathedrals need architects, they need a good structure and a big design upfront. The design of the cathedral is important, there is no room for variation, for spontaneous ideas of the people building it.

The Bazaar

In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena – or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.

There is no architect for a bazaar. Somebody provides space, sets up a number of rules and invites people to participate.
The bazaar is free. If you see that there is a certain product missing on the market, you can simply open up your own stall and wait for people who would buy it.

Linux is based on the idea of the bazaar. ESR even calls this model “the Linus law”.
In the first days of Linux, a lot of people did not believe that Linux would work out. Everybody can participate? Everybody is able to add a feature, drivers, modules, and functionality? This is going to end up in an inevitable mess. People will introduce bugs and unforeseen bad interactions since they don’t understand the whole software. Linux is going to collapse under the weight of uncoordinated efforts!

Today

Today we know that “Linus Law” worked out. Linux is not less stable, in contrary, it’s used for the majority of mission-critical systems. It’s the foundation for the major cloud providers today.
The bazaar model itself was a major success, too: Github is basically a technical implementation of it.
The late success of the most popular programming language today, javascript, is based on nodejs and npm – another bazaar.
PHP has been a bazaar right from the beginning. It was always easy to participate and provide extensions to the language. I have been working with several release managers and core developers of PHP. If you know what you are doing and willing to discuss your ideas with other developers it was always easy to play every role in the PHP world.

Agile Architecture

Cathedrals and Big Design Upfront

The original idea of software architecture was a cathedral approach: start with a proper, well designed and understood big design upfront. Start to implement after you defined how your architecture is going to look like.
If we don’t know how our software is going to look in the end, how should we define the architecture for it now?
Maybe somebody invents new technology that is going to be useful for our platform in 3 months? Maybe we discover that one of our base technologies does not live up to the promise it made?

We know that we need to be prepared for change when it comes to internet applications. Youtube started as a video dating platform, but the customers rather wanted to upload videos. Slack was an interactive game, but the chat appeared to be more useful. Twitter was a podcasting platform before iTunes came and they had to reinvent themselves. Paypal was a palm pilot app that nobody used, Pinterest was a mobile shopping platform with no demand. None of them would have survived if they would have kept their initial architecture.
But how do we create an architecture if we already know everything is going to change?

Emergent architecture

Agile development answered with emergent architecture (see https://submissions.agilealliance.org/system/attachments/attachments/000/000/2342/original/Emergent_Architecture_-_Just_Enough_Just_in_Time.pdf). We’ll figure out the right architecture on our way to the final software. KISS (keep it simple, stupid), DRY (Don’t Repeat Yourself), YAGNI (You Ain’t Gonna Need It) are parts of an emergent “just enough architecture” strategy.
In emergent architecture, it’s ok to change your mind and choose another architecture a few sprints later. It’s ok to try out new architectural options as “Spikes”.
But emergent architecture is not cowboy coding, where everybody implements whatever he wants – it’s an architecture that allows changing your mind.
It’s not possible to change your mind if your software isn’t flexible if it’s not modular. It’s not possible to change your mind if your software is entangled. It’s not possible to change your mind if you rely on a certain component, like a special database system.
The easier – and cheaper – it is to change your mind, the better the architecture can adapt to changed or newly discovered architectural requirements. Strategies like the SOLID design principles or microservices try to achieve exactly this. If it’s hard or expensive to change your mind it’s not emergent architecture, since it relies on learning, adapting and trying out new things.
If everything works out you end up with the architecture that is the best fit for your current requirements – and not, like in Big Design Upfront architecture – the best fit for the idea of the software you had before you even started developing it.

Bazaars are distributed emergent architectures (on steroids)

The bazaar model already implemented a lot of emergent architectural patterns, like the Unix principles, that have been a major influence on microservice design.
And it implemented emergent architecture in an even more powerful way – as something that was free, attractive, open and distributed. Why evaluate 2 spikes at the end of the sprint if you can have 10 people implementing their ideas of a good solution for free and trying them out for months? Why not adding other peoples brainpower to your ideas and implementation and have them suggest – or even provide – better implementations?
It’s useful to be able to choose one from multiple solutions for a certain problem. If a lot of people do this it’s even possible to figure out what solution is the best fit for most of the problems, simply by looking at the number of downloads or GitHub stars.
Bazaars are emergent architectures on steroids. They provide a multiple of implementations and empirical data, a multiple of learning and adaption.
Does this kind of architecture result in beautiful implementations? This just happens if beauty is the major driver to choose an implementation. Most of the time it is not, it’s simply the most usable, the most useful implementation. Whatever the benefits of using a certain module are, the one with the best overall fit is going to be the most popular.

PHP as an application of distributed emergent architecture

How do You create a platform that works well with emergent architecture?
Obviously, it needs to allow experiments, and these experiments should be fast and easy to implement.

That’s how PHP does it:

Existing open sourced functionality

There is already a mountain of existing PHP functionality out there. It is GitHubs fourth most popular language, and most of the repositories are free. There are 4-5 major solutions for every kind of problem, be it CMS, e-commerce or frameworks, with large infrastructures with hundreds of additional plugins and modules behind them.

PHPs builtin functions

PHP comes with thousands of builtin functions for the average setup. You need something? It’s probably already there. Is this good design? Certainly not! Will you be able to move fast? Yep.

Focus on functionality, not on parsing HTTP, restoring session variables, typing or memory management

When the PHP script starts all variables, request or session variables, are already there. By default, you don’t need to care about typing or memory management. There is no HTTP-event loop, everything is already done. With fewer things to care about you get faster and cheaper experiments.

Fast feedback for local development – the inner loop

Hot Module Replacement? The fast save-reload-check-cycle was a part of PHP right from the beginning. The default delay until a developer sees if his idea actually works out is 1 second.

Fast feedback for teams – the outer loop

PHP deployment is file-based and immediate. Update the file and you’ll see the changes with the next request. There are no compile steps, no build artifacts needed to see a change another developer created on your machine or in the test environment. A simple file transfer – most of the time as a part of the version control system – is enough.

Fast integration of existing libraries

If it can not be solved in PHP code, it’s easy to create a new PHP Extension. It’s even possible with limited C knowledge, and most of the times a few lines of code are enough to integrate a function.

Star Treks BORG as a role model

The PHP culture is not afraid of stealing ideas. If something looks interesting, it will be assimilated. If there is a nice idea in the Java world, in Golang, in rust, in ruby or python – we are going to steal it.

All these strategies support PHPs bazaar architecture.
They make PHP a marketplace of ideas. It’s not build to look beautiful as a cathedral. It’s not there of aesthetic purposes. But it is made to provide fast easy solutions for most of the requirements you have.
And if there is a solution missing for exactly your problem, most of the time it’s easy to create it.

So, why – and when – should i use PHP?

PHP is optimized for environments where you don’t know for sure what is going to happen next. Not by design – by emergent practice. By the survival of the fittest for the purpose.
PHP could not provide fast and cheap solutions and feedback loops for most of the problems if the focus would be beautiful design instead of, well, fast and cheap answers and feedback loops.

If you know exactly how your future will like – don’t use PHP. But if your future is unpredictable and risky – PHP will help you to figure out what works and what doesn’t in a very efficient way.

Do you know if there is a user group in your area? And if so, have you been there? If you answered one or both of this questions with „no“ and you are wondering why you should care? Let me tell you a little story.

Read more

Monday morning. Your previous project just wrapped up, and they are going to assign you a brand new one. They even promised you the lead on this project. Who said Mondays couldn’t be great?

A few hours later and you are staring at the most dreadful code you have ever seen — controllers of more than a thousand lines, PHP that injects jQuery in the views, raw SQL statements that could challenge a Dostoyevsky novel in size. The list goes on and on. This Monday is going to need a ton of coffee.

The previous few lines might sound very familiar to you. You might even be working on a project like this at this very moment. If that is the case, … lucky you.

Why do these horrible applications exist?

Most applications don’t start like this. As you know, green field applications start full of hopes, dreams and rainbows.
A new business idea gets launched. It does something small, pretty good. People like the application. They like it a lot. More and more customers flock to the application. You excitingly add more functionality to your small idea. Soon, one of your more prominent clients, asks for a very valid use case.

Hmm, you haven’t thought about this particular flow in the application. To be honest; the application doesn’t support it. However… it’s a big client, and it’s a great idea. You know what, this small little hack won’t make the difference. We’ll document it, so everyone knows about it.

Fast forward a few months. You have a dozen developers working for you, and your Kanban feature board is filled to the brim. The strange thing about the board, however, is that most of the features on that board don’t come from your hand, they come from customers. Moreover, they all want concrete things very tailored to their workflows. That little hack that’s been made a few months ago is now not even considered a hack anymore; it’s just how the application works. Moreover, if you take a step back, most of the application is now a collection of these small little hacks.

You might think that this is a horrible product, and from a code perspective you might be right. However, from a business perspective, this is a vital process. The product has a ton of customers, and they are invested enough to want to tailor it to their workflows and they even reach out to you with suggestions. Granted, not all of these suggestions are great, but they wouldn’t come forward if there weren’t a need for them.

Is this the low point?

However, now where does that leave you, It’s entertaining to have a company with many customers, but at the end of the day, you’re still the one that is in the trenches of despair.

Not necessarily;
Having a product like this tend to generate income. The most significant part of that income is invested back into the project. Once the legacy code hampers the production of new features or generates too many bugs, the discussion surrounding refactoring parts of the code tend to start getting more and more speed.

Once you start refactoring, you suddenly notice that you have so much value in front of you — a ton of use cases already implemented, a wealth of user behaviour and data, metrics and most important of all: the budget and infrastructure to match.

Working with legacy day to day

Most refactorings tend to start with the question from management that is frequently a variation of: “what are the worst parts of the application, and how can we make them better”. This sentence is poetry to a developer’s ear. A great chance to go over the entire application note down the pain points, look at technologies that might ease trouble, have lengthy discussions with colleagues about the architecture of the pesky service classes. Not only are you going to learn a ton on the technical side of things, socially you’re going to improve in ways of persuasion and proposing ideas.

After a while, the most significant part of the spec will be done. Moreover, I can guarantee you that you’ve never been so excited to work on the project before. You can now look at the project and see a road to be walked, where before it was just an end to a means.

Now comes the tricky part, refactoring one of those huge files. The first time you read over the class, you might get some doubts about this whole refactoring stuff. Luckily you stick to your means of attack and write your first end to end tests. Once you’ve established a safety net, you regain a big part of your courage.

Ok you think, this piece of code I might be able to extract to a separate class. You write the unit test. You extract the code, and everything is green. Ok, great start! Let’s do it again.

A few hours later you stare at the construction you’ve made. It’s a vast improvement of what it was before (every single indentation you fix is an improvement), but looking at the loose classes, you can see some definite improvements still. You could leave it as it is, and that would be great, or go further. Either path you chose, at one point you’re going to create a PR, and sit back and stare at the diff screen of your favourite git hosting service … what a beauty.

Growing with the application

Working on applications like this is all about responsibility. Every decision you make as a team will impact you in the future, in a good way and sometimes in a not so good way.

This kind of pressure might sound like a burden, but in reality, it is indeed a blessing. It forces you to slow down and think about your actions as a team. Should I write a test for this? The answer is going to be yes, cause once it has a test, it’s going to part of the test coverage for maybe years to come.

So that’s the beauty of legacy code: You get a rough stone that you can shape into a gem. The pressure of delivering new features won’t be lower on a legacy application over Greenfield, but management often understands the need for refactoring and architectural meetings better.

Moreover, all the technologies and paradigms learned in the refactoring of legacy code are invaluable when you move on to Greenfield projects as you now have the context for the need for value objects, testing and decoupling.

So yes, if you’re about to start on a legacy code base. Lucky you. You’re about to have one hell of a ride.

Ps: Happy birthday Taylor Swift