To feel good

Not too long ago a new job title started to make an appearance in German companies:  the “Feel Good Manager” – a name that might bring an ironic smile to some native speakers’ faces, as a colleague in New York confirmed. You see, a “Feel Good Doctor” would be someone who prescribes drugs that promote good feelings beyond the actual medical need – and there is a similar ring to “Feel Good Manager”.

But the intention behind the position with this title is to have someone responsible for employees feeling good on the job (in a healthy sense). The idea that people should enjoy being at work is a great one and I am completely behind that. So certainly this is a good new trend. Or is it?

That depends, I would say. To feel good weiterlesen

The Digital Agency

Liebe LeserInnen,

Der nachfolgende Beitrag wurde in gekürzter (deutscher Fassung) in der LEAD digital Nr. 22 am 30. Oktober 2013 veröffentlicht. Viel Spaß beim lesen.

A digital agency is a tech company.

This article is an examination of one aspect of what a digital agency is or should be. It is about an aspect than has some misconceptions. One of these misconceptions, perceives that digital agencies are there for making pretty images (digitally). Another comes from “serious” software companies. They often have the attitude, that digital agencies are not making “real” software. To clear these up, I will ask you to change your assumptions and accept two claims.

Firstly, a digital agency is not an advertising agency on bytes.

Although digital agencies are involved with advertising and marketing, they are making things that have programmable code.

And secondly: anything that has programmable code is software.

A digital agency understands the medium it works with and continues to adapt and grow with changing technology. The medium is not just a surface for static content or moving images. It interacts — and soon there will be little left that does not interact.

If we are creating software as soon as we start writing code, then digital agencies are involved in software processes — no matter what they are making. Therefore they not only need to understand the technology but also they (and their clients) must learn software development processes.

Paradigm change

Software is not put together on a conveyor belt. It is a creative process involving many different skills — from start to launch and beyond. Successful, creative, innovative projects require a paradigm change.

“Agile” is a buzzword that even classical agencies are starting to use. But “agile” is not just about being flexible. It is about re-thinking processes and about involvement.

Embracing change was a new thing for software developers back when people were used to writing everything down ahead of time — getting it absolutely right — before a single line of code was written. Unfortunately it is almost impossible to get it “absolutely right” at the beginning, and so agile processes emerged.

But (classical) agencies have always been used to change. Painfully so. The attitude has been, to always say “yes” to the clients wishes, no matter how late or difficult the change is. The problem here is usually misleading or missing communication, which in turn is the fault of “factory thinking” and not because a client is “fickle”.

“Factory thinking” is what happens when a client’s “order” is put on a conveyor belt through an agency, progressing through different teams who know nothing of project until it has been placed on their desk. The client sees the project again at the end of the line. Most likely, it is not quite what the client was expecting, and last minute changes and corrections are the consequence.

However the solution is quite simple: Involve everyone in the entire process.

Involvement and Partnership with the client.

At MINISTRY we have been involving our clients in the entire project process for several years now. Although some clients are still hesitant, those who have embraced this kind of partnership, have enjoyed successful and creative processes that have lead to great products.

Involvement throughout the process does not mean more work. It is a shift away from concentrating on the beginning and end of a project. Cooperation is spread over the whole process. By doing so, the risks of not being on time and of dissatisfaction, even conflict, are practically eliminated. Most last minute changes are due to misunderstandings. The agency misunderstood what the client wanted. The client was not so sure what he wanted. The client misunderstood what the agency was planning.

Involvement is a cure for this. It allows us (the agency and the client) to adapt, adjust and prioritise. We can decide together what we can change immediately, what we can do later in order to stay on time, what cannot be changed and must be accepted. The consequences of every decision are carried together.

Scrum & Co.

Methodology is a great place to start, but internalising the principles is more important. At MINISTRY we began a few years ago with “Feature Based Programming”, a method shared with us by Stefan Richter of freiheit.com. Currently we are trying out “Scrum” for larger projects. But in their basic principles all agile processes are very similar. Here is an example of how we use them:

A project typically begins with workshops involving the client, a project manager from the agency and people who have the skills of a developer, a quality manager and a designer. The purpose of the workshops is for all to find out what the project is about, what the desired result is and what we can do to get it done. The result of this phase is not a book about the project, but rather a feature list, which describes what we plan to do — in a style and language that all participants understand. Features can be split it up into blocks and can be made into a roadmap. The important thing here is that we try to get it right from the beginning, but it is possible that some change will come with time. It is important that we define what we are going to do, not how we are going to do it. That will be decided in the next phases.

There is an important difference between this process and trying to get it “absolutely right” before programming. We define what we want to do to the best of our knowledge, but we leave room for course correction along the way, and we never say “how” we are going to something, because we often cannot know that until we get there.

The process that follows is a series of iterations and checking back with the client. Milestones can be presentations of a “clickable” prototype (wireframe), a style guide or layout. Later software releases allow the client glimpses of the real working product, where a designated set of features is already programmed. The product takes shape and is being created at the same time and the client is involved in the entire process.

This is quite different than showing pretty designs at the beginning and coming back shortly before launch to make sure that all that was done in the meantime is OK for the client.

Since designers and developers are involved in the whole process, we can assume that we are saving time by not coming up with ideas that might not work or might take too much time. Since the client is involved throughout the process we can assume that we are staying on track with what the client wants and can adjust throughout to make sure.

Cooperations

Some agencies have entered partnerships with tech companies. That’s fine as long as the technology partner is involved in the entire project process.

The advantage of being a true digital agency (and therefore a tech company) is that you do not have to double up. Each skill is already based on an understanding of making software, whether the consultant, the project manager or the designer — and needless to say, we have developers and testers on each project the whole time.

And if you buy my assumption about what software is, then any agency without skills in the process of making software and knowledge about technologies involved should not use the word “digital”. A digital agency that does not do software is like an automotive designer, who does not know how to build cars. You might get a lot of fantastic looking vehicles out there that don’t work, or many very similar looking functional cars.

So what is a digital agency?

Digital agencies are tech companies that are experts in making software that is enjoyable to use, nice to look at and that attracts customers. They understand software processes and can create fantastic functional interactive products. Incidentally this also has something to do with advertising and marketing in a digital world.

Keep it Simple. Keep it Fun.

We believe that neither a framework nor a CMS should be difficult to install, configure or learn, nor should they make anyone program in a rigid or cumbersome way. In other words, they should make programming more – not less – fun. It should however take away a lot of the tedious stuff – the things that distract you just when you were getting some really good ideas.

The philosophy of making software for developers

Eliminate the tedious. Well that is basically the idea of a framework. We want to give you a frame that takes care of the boring things that are always there and let’s you do your stuff. All frameworks should fulfill this function, otherwise they don’t deserve to be called frameworks.

Don’t take away the interesting work. We want to let you, the developer, write your own code in your own way. We want you to have fun programming. Most developers enjoy programming and don’t want all the work taken care of.

Don’t make the developer do awkward things, like dealing with complicated class systems or even learning a new scripting language or templating markup, just to work with one particular framework or CMS. Of course, learning is necessary in order to work with any unfamiliar system, but it can be kept to a minimum and the more you can use what you already know, the better. Keep it simple, don’t just say it is simple. Don’t organise because of a misguided love of organisation or because that is “the way it is supposed to be done”. Inheritance is great, but hard to follow in a framework. Conventions only help those who have memorized them.

Never implement features that “might” be useful. Make what is needed, when it is needed. A basic “getting real” principle, worth gold in a project by developers for developers.

Because of these principles – or at the beginning at least a vague idea of them – we set about making a new framework, and later built a new CMS.

Are these ideas so unique? Certainly not, but we have seen few examples of products for developers that follow them, and lots of tools that are difficult to install, learn and are useful only after extensive learning. Tools that lead developers to describe themselves according to being able to work with them. We don’t want developers to write „MorrowTwo Developer“ in their CV instead of „PHP Developer“. That doesn’t make sense. Any more than an illustrator describing himself as a „pencil pusher“.

A philosophy of simplicity has found broad acceptance in web development, an approach that begins at the birth of every new project. But it seems that tools for developers are still expected to be complicated and full of features. Maybe because developers have a hard time thinking „simple“ and, to be honest, it wasn’t easy for us either.

Re-programming and avoiding featuritis

Morrow – the forerunner of our framework “MorrowTwo” – began as a project our own use. The first ideas came about as we started combining the systems we had each created for ourselves as individual developers. Starting in a kind of pair-programming process, we created Morrow – a full framework, that we considered more of a proof-of-concept than a finished version. After using Morrow in dozens of real projects, we sat down and discussed all that was good, and all that bothered us.

First of all we re-defined the way classes were to be used and refactored the way controllers work. But going further than that, we realized that we still took too much of the programming away from the developer. We had created a lot of conventions that allowed the developer to do things in a single line of code. The problem with that, was that the developer had to learn these conventions in order to use the features. Therefore we threw them all out. The consequence is that you, as a developer, have to write more code, but it is code that you write without having to refer as much to the documentation.

When we started working on our CMS “/f/” (pronounced “SlashF-Shift7”*  or just “SlashF”), we had already gained a lot of experience with working with eachother and had learned to look for the signs of featuritis creeping in. For every feature one of us wanted to add, the other asked the question: Do we need it? Do we need it now? Most of the time, the answer was “no”. It was actually quite like a game.

The results of these processes, I would now like to decribe in some more detail in the next two sections.

The products

MorrowTwo: efficient web development

What does efficient mean? It means no set up and no configuration of the framework itself. It means understanding quickly how the system works. It means the basics are taken care of and the developer can program his in his own way.

What are the basics? In our opinion they are: a simple controller/template setup. It includes a simple handling of user input, provides speaking URLs automatically, helps in the generation of valid links and navigational elements. Also multiple language and locale handling are a must. Multiple projects and sites should also be possible. And of course logging and debugging should be simple and ready to use. Ah what else? Of course, session handling and output to different types of views with the appropriate headers.

When all that is basic, what could possibly be optional?

There is quite a few left over. But instead of giving you a complete feature list now, I would like to refer to the project wiki, which provides you with the documentation of the classes we provide with the framework. If you feel like anything is missing, you can create your own classes, or use classes provided by other developers.

There is one more very important feature to mention. Programming easily isn’t everything. The product you develop also needs to be efficient. We have trimmed MorrowTwo for performance. The entire code has been analysed with XDebug and then optimised. To increase output speed even more we have implemented a soft HTTP-Caching with automatic generation of ETags. You don’t have to do anything for this. But if you really want to decrease the expenditure of your own code you can also implement hard caching by using the classes we provide for that.

SlashF-Shift7: Just managing content

Managing content is a difficult topic. We decided to make it easier. Not just for the editor of the content, who should not be confronted with too many options and ways of doing things, but also for the developer. Our goal was to allow you to set up the content managing part by creating a few configuration files. That’s it.

As a main concept of the CMS we separated the management of content from its presentation. In order to present the content, you, the developer, can use a framework, like MorrowTwo, or just write your own PHP code. You can get the content then either directly from the database or can use a class that we provide to access page data. The two biggest advantages of this are that the output is not limited to HTML and you have complete freedom to program in the way you are used to with the technologies you are used to using.

For managing the content you have a range of fields that you configure to your needs. You group these fields together to form data sets for pages or list items. If you need your own custom fields you can add these by extending classes that we provide. The result is an interface that is easy to understand for those who will be adding and editing content.

Keeping ourselves to the essential features, the decisions we made were initially based on experience. We only put in features that we have actually needed for real projects, but not ones that sounded like good ideas, but we have never actually used. The list was then adapted to needs that came up in the subsequent projects we realised for ourselves and our clients.

At the current stand, we have a preview and publishing system, simple group permissions, automatic support for “speaking URLs”, and simple file management including IPTC field editing, to name a few features. Of course,  /f/ has been set up to handle multilingual content from the very beginning.

Currently /f/ is in the refactoring phase. When that is finished we are also planning to provide it for you for free.

Creating and sharing

Basically it is not hard to program for developers. From the beginning on, you are making something for yourself. When the goal is to make something that you can enjoy using, if you remember – and keep reminding yourself – to only implement the necessary and keep in mind that others could use your application and that they should also have fun with it, then you are likely to create a great product.

MorrowTwo has been used for years now by Ministry employees and freelancers working with us. The feedback we have received has supported the ideas above. Once you have tried MorrowTwo yourself, we would greatly appreciate it, if you would share your thoughts and feelings about the framework:morrowtwo@ministry.de.

If you would like to be notified when /f/ is availible to the public, write us at slashf@ministry.de.