Ein paar Zwangsmaßnahmen

Ich habe 2 Accounts bei der O2. Eines ist der Handyvertrag und das andere ist ein ehemaliges AliceDSL aka o2 DSL.

Beide Produkte habe ich schon lange und beide Produkte sind nicht für ihre Produktqualität bekannt. Jedenfalls wenn ich mich in meinem Freundeskreis mal so umhöre. Mein Freundeskreis ist es auch der mich dazu überreden will doch bald ein anderes Produkt zu kaufen. Wenigstens um auf Twitter Ruhe zu haben. Ich glaube das werde ich bald auch tun. Warum?

1. Mit dem Handyvertrag konnte man, nach Überschreitung des monatlichen Volumens für die “Flatrate” nicht mal mehr einen Ping senden.
2. Die Handynetzabdeckung von O2 verbesserte sich für mich die letzten 2 Jahre nicht. Die Bahnstrecke Hamburg-München wäre für mich recht wichtig. Leider scheint es finanziell bei O2 nicht zu reichen dort noch mehr Masten aufzustellen. Das Funkloch zwischen Hamburg und berlin ist ja auch weithin bekannt. Warum ich allerdings an großen Bahnhöfen in Hamburg kein Netz habe (z.B.Dammtor am CCH) oder dem Hauptbahnhof (ca. 50 des Jahres) erschliesst sich mir nicht.
3. Das DSL ist leider nicht mehr als Flatrate zu bezeichen. Schon über eine Woche habe ich Pingzeiten von bis zu 40 Sekunden und immer nur wieder via Twitter recht lakonische Antworten da sei eine Störung und man sei dran sie zu beheben.
4. Die Preise für O2 sind zwar im unteren drittel, aber die Leistung ist leider immer “borderline” dazu, dass man nicht kauft was man versprochen bekam. Siehe 1. und 3.
   

Ich glaube persönlich einfach, die O2 spekuliert hier einfach auf ruhige Kunden die notfalls mit dem Geldbeutel abstimmen. Dann lohnt sich so etwas auch. Lieschen Müller wird es egal sein wenn versprochene Merkmale nicht funktionieren und von denen gibt es genug dass sich der betrieb dieses Netzes in diesem Zustand lohnt. Dann ist halt das Internet mal ne Woche “doof”.

Die Kunden sind für die O2 halt billig. So billig, dass es sich lohnt die Kunden einfach per Social Media Accounts abzuspeisen, den Kunden in Support Tickets immer nur die selben Textbausteine anzudrehen. Teurer wäre es Produkte anzubieten, welche die Merkmale auch haben die versprochen wurden. Es ist irgendwie wie bei Abmahnanwälten. Das lohnt sich halt auch nur wenn der “Kunde” still hält und zahlt.

Dafür können die Kundenbetreuer nix. Das ist mir klar.  Die arbeiten nur ihren Job und machen das was vorgegeben wird. Ich werde bei O2 auch immer nett bedient, aber im Endeffekt ist das was da passiert halt für mich eine ganz blöde Geschichte. Mein Router, der sich immer mal wieder verabschiedet, wurde auch nach mehrfacher Nachfrage nicht ersetzt. Maximal bekommt man ein “wir monitoren mal deine Leitung”, dann aber kein Ergebnis. Meine Annahme: Das ist für die O2 einfach billiger 😉

Zwangsmaßnahmen? Welche Maßnahmen? 

Ich habe die Schnauze recht endgültig voll, aber einfach zu gehen wäre für die O2 ja recht und billig. Es sind ja nur 70 Euro weniger einnahmen. Das wird niemanden dort dazu bewegen etwas zu verbessern. Darum werde ich, bevor ich das Unternehmen als Kunde verlasse noch einige Dinge öffentlich dokumentieren.

1. Die Qualität meines DSL Zugangs wird ab nun dokumentiert und gelogged und veröffentlicht.
2. Selbiges geschieht mit meinem Mobilfunkvertrag. Ich möchte einfach messen wo in Deutschland das O2 Netz wie gut ist.
3. Alle Interaktionen mit O2 werde ich auf einer Timeline hinterlegen
4. Die Qualität von Ersatzangeboten wird dokumentiert
5. Das ganze kommt auf eine Internetseite die dann auch mal im Google Index landet. Seht es als eine art “Citizen Journalism” im kleinen. Ihr könnt mich auch als “Grumpy Old Man” beurteilen. Mir egal, ich mag das einfach nicht unkommentiert stehen lassen.Die O2 macht das ja mit mehr Kunden.
6. Ich werde mir Alternativen suchen, aber die Accounts beibehalten. Ich bin jetzt einfach verärgert. Ich messe einfach nur noch wie schlecht (oder irgendwann gut) das Netz ist.

Da sind ganz interessante Sachen bei. Das alles zu automatisieren wird Spaß bringen und ich kann endlich einen Raspberry PI bestellen und damit spielen.

Ich würde ja gerne die Zeit am Wochenende mit anderen Dingen verbringen, wie z.B. Online-Spielen oder mal nen guten Film zu schauen. Das geht aber leider momentan nicht und darum ist etwas Zeit vorhanden. Die werde ich gut nutzen und etwas Software entwickeln, ein bisserl Monitoring betreiben und die ganzen Daten veröffentlichen. Zukünftige Kunden der O2 können dann in Zukunft selbst entscheiden welche anderen Alternativen sie haben und wie gut die Qualität der angebotenen Produkte wirklich ist.

Ich bin gespannt was bei dem gehacke rauskommt.

 

Weekly recap Week #38

This week was more about building my own things aka website.

Jekyll is still one hell (good) of a blogging and web site system. If you are hosting your own WordPress blog and you are technical capable: Look into Jekyll. It’s a complete static website generator using markdown as a file format. I love it and I am still a bit on the learning curve.

There is a yeoman generator for Jekyll and Bootstrap that makes some things easy. You might be better off with starting a plain Jekyll project and wiring everything up yourself. However it is a good if you want to see how things can be wried up and have a basic idea how bootstrap works.

I found out what copywriting is. It’s essentially writing for marketing reasons. Aha. Thank you wikipedia. One of these words that I listened to multiple times but never really questioned what they imply.

I decided on the kinds of trainings I want to provide as a “standard” to my customers. These will be: “Extreme Programming”, “Pair Programming” and “Userstories with Gherkin and BDD”. Watch out there: News will be out soon. if you want early information: Shot me a mail.

I a talk about clojure script (Clojure Script: Lisps revenge) kept me up at night and  I blame David Soria Para now for me having thoughts of trying it. It looks like the hell of a beast of a programing languages but looks like it fixed a lot of the functional fuckups that are in JS. And ITCOMPILESTOJAVASCRIPT!!!EINSELF!!!

10 tips for the XP Practice “Sit Together”

James Shore describes “Sit together” in his book as

“Sitting together fuels team communication. This has impressive results, cutting time-to-market by two thirds in one field study*. It enables simultaneous phases, eliminates waste, and allows team members to contribute insights to others’ conversations.

To sit together, create an open workspace. This takes longer than you expect. Organize your workspace around pairing stations, locating people according to conversations they should overhear. Provide plenty of whiteboard space. Make sure there’s room for personal effects and a place for private conversations.

Open workspaces are hard for some to accept. Get team members’ permission before switching, or they may rebel.”

1. Sit all the disciplines together.
I often see designers skipping this one and staying with their designer teams. Not so good. Everyone should be on the product they are working on.

2. Agree to common rules explicitly
Different people have different needs and desires. Talk about them and write them down. After a few weeks: rinse and repeat. make this explicit

3. Must not be in a room, but can be close
A glass wall often does as well. If I can see my Product owner (a role that requests own rooms very often in my experience), I can approach him.

4. Adapt your visual management
If you are doing hardcore Scrum you might dive into Kanban now. There are different disciplines and roles in the room, working on on one thing. So the normal Scrum Board most likely will not cut it. A good place to start is Kanaban.

5. Rituals! Rituals! Rituals!
I have heard of a “Disco Friday” where teams would play nice music all day long aloud on friday or seen hourly Nerf gun matches. These rituals help to firm groups and keep them in high cohesion.

6. Style it
Invest some work in styling the place. Some lights, LED ambient illumination, posters on the wall etc. will really help teams to form and stick. Make sure to provide a budget.

7. Clean it
Once a week/sprint: Clean the workplace and bring everything in order. Its a very short procedure for most places and it helps providing general order and cleanliness.

8. Have the Meetings together
Do not let the “Backend Guy” bail the Grooming when you are working on Frontend Stories. Do not let the designer bail as well. Everyone has to learn what the other disciplines do. When someone sits there and does not get it: Help him understand. Re-Arrange Groomings so that there are Stories of any Kind. You know the vertical slicing thingie? You should do it. And no .. neither the designer nor the tester will bail the Retrospective. It takes disciplined and willing teams to practice it this way. But in my experience: The seasoned crafts(wo)men will happily participate.

9. Have a extra room for “Discussions”
When different trades of craft work together, there is a lot of need to discuss things and talk about it. You will need a room for this since every discussion will be a interruption for everyone else in the room. Buy a set of high quality noise dampening head phones. I am working at a client here in Hamburg where you have small chambers for working 1on1 as well as meeting rooms that are general available for phone conferences etc.

10. Have more than enough Space
Even People with Computers need Space to work and think. Provide this. Don’t make cross-functional teams and cram them in a small room and be surprised you get a lot of complaints from the inhabitants of that room . If you cant afford space, maybe do not hire developers at all. There are regulations for how many office workers can be in a certain set of size here in Germany and I have seen several occasions where these laws where used as a common denominator of how many people fit in a room. This is not the way it works.

So this is what I came up with. What are your Ideas?

Weekly recap – Week #37

This week was code, code and code.

If you look for a way to generate a appcache.manifest and make your page more available for offline usage, grunt-appcache is your friend.

Manifesto is a anice bookmarklet to let you check HTML appcache manifests.

Using input fields with an TabletPC might pose ne challenges to event handling as I found out. Dismissing the virtual keyboard might break your layout.

Instead of using backbone and wondering about the amount of boilerplate to write, I might have a look into the new apper framework for single page apps. Nice one.

Math.js just got a 1.0 and I find the new filter feature very interesting. You might wanna check your js codebase for calculations that could be done with mathjs in a simpler way. Still I heavily recommend it.

8 tips for the use of coding conventions

Coding conventions sound so easy, but get hard over the course of a longer project and with bigger team size. With a little feedback and forth with Johann Peter Hartmann, the following principles for a coding standard were up for discussion.

• understandability – The conventions should help the programmer to understand the code and should be easy to understand themselves
• learnability – It should be easy to adopt and learn a coding convention and the convention should help the developer to easily find a way into a codebase
• attractiveness – It should be attractive to adhere to a certain standard
• analyzability – The standard set itself should be machine analyzable. It’s either THIS or THAT, not MAYBE, SOMETIMES or OFTEN. 😉
• changeability – The standard should be easy to change and changes to the code, by a new standard, should be easy to do as well.

My list of tipps should help you find a standard and keep it up.

1. They apply for everyone in the team.

No developer, in no situation should be exempt of the conventions. It might sound dogmatic, but this is a rule that applies for everyone. Even for $pointyhairyboss, if he is still pushing to the codebase.

2. There is no perfect convention for every given project.

I see this discussion revolve again and again: Developers looking for “the standard”. Where do I set my braces, which kind of whitespace do I use? Please tell me. I am to smart to look for THE standard, give me any standard and I will adhere to it.

3. Automate checking

No one wants to check, what could be millions line of code, by hand ot just looking at the code. Tools can help you with that. What ever you decide, try to create an automated check for violations and make this one available to all the developers working on the software.

4. Have examples and explanations

Coding conventions may seem to be a very subjective thing. But when explained properly, in a markdown, text file or wiki page it gets easier to accept to code by standards that are not your own (yet).

5.  Your codebase must have 0 violations at all time 

With command line tools and checking before you push stuff to a repository, this should be easy. There might me exceptions, but make sure you group them into modules exempt from the checking process or make other wise sure the initial thought of a same structured codebase does not get undermined.  See 6.

6. Change if required

If the rules don’t fit, change them to better ones. Migrate the module to the new rules. Do not only change the rules. Change the code as well.

7. Everyone is responsible not only for his own conventions 

Where ever you are in a pice of code, you are encouraged to fix any violations or add a example here and there. Didn’t you find enough comments? Cool, add some.  Something is formatted wonky? Fix it! Somebody used spaces? Change it to tabs if the spec says so.  Where ever you are in the code, a OneButtonTest will be a good practice to look at.

8. Make conventions per module, not per team. 

Different modules might be written in different times and adhere to different standards. So splitting up parts of your software that follows a very different style might be reasonable. In Javascript and a browser environment you would use tools like component and bower to get things back together.  Small modules help you maintain different styles. Think about it: If you have a long running project, it’s very likely you will have more than one standard. And small modules allow for different ones in different occasions and situations. One argumentative nail in the coffin of Big ball of mud designs G*

This was my list of hints. What are yours?

Weekly recap – Week #36

This week was full of interesting stuff

• COACHING: I had to do some research on feedback types and styles. I stumbled on this document, giving a little more background on the special properties of feedback.
• TRAINING: Another research task was on the basics of lean. I am hammering together a workshop on the Lean Basics and Kanban, so I needed all in one Place on this Cheatsheet. I need to recreate this with CC.
• FUNDING: I did choose a website Theme and took a deeper look into the Onepager from http://www.rebelatheartpr.com/ which will serve as a good example for structure and approach. 😉 My theme of choice.
• CODING: If you do anything tech related to web and did not read the HTTP Status Codes RFC, I urge you to do so. It is !IMPORTANT
• NEWS: Mytaxi was sold to Daimler. I am applauding the team + Nic Mewes and Sven Külper. A german startup dream come true I guess. That is something that other big german funders never did: Building something original, as one of the first movers, not cloning anything. You better worship that ;))))
• CODING: A HTML/JS based editor. Smalleditor got my attention. I like how it is made. Definetly something to look into. https://github.com/jdkanani/smalleditor

Lots of different things. Interesting times.

 

Weekly recap – Week #35

Following the practice of Martin Wolf, I am now posting a recap of things I do over the course of a week. So you can see not only what is on my mind, but what I am actually doing

Backbone.js 

• backbone inheritance. Looks easy, but there are quite many ways to do it.
  “Backbone.js & inherticance” gives you a intro
• And if you are looking how to inherit those defaults you might wanna see this
  Stackoverflow thread
• Want to validate backbone models? I seem to come back to
  “backbone.validation” again and again
• You might wanna check the common pitfalls early on
  “avoiding common pitfalls“

Development

• I am a big fan of Grunt.js but I must admit: Gulp is awesome. I got really tired of big configuration files that seemed to be a mistery after a while. You might wanna read the
  “quick intro to gulp.js” and give it a chance. You will not regret it. Lean and Mean I say.

Blogposts

• Olaf Lewitz has a piece on happiness, money and a interview with the CEO of Krankikom GmbH
  “The most important things in life“. This was my blogpost of the week.

 

Ideas for modern coding

If starting a new web project follow some basic principles

• Start with deploy code – It must be deployable from moment 0
• Use Unit- and Functionaltests
• The deployed code is testable and thereby you can verify it
• Use Virtual machines to recreate the live environment
• All is in GIT – dev and ops code
• Use cont. integration and cont. deployment from moment 0
• Static analyze the code – it’s cheap
• Build in monitoring and logging
• Whatever you do, write some docs, build them automatically

I think I will try this. Using this one would end up with a recreatable environment, that 5 years later, everyone who wants to use the software, can recreate. It’s not ma a magic bullet, but I think it could speed up a lot of things heavily.

A day setup can save you a lot of worries. The less you depend on things made “by hand” and if you put something aside for a while, you will be able to return easily.

 

About a Bridge Thread

Reading the C2 wiki, in the context of extreme programming, a bridge thread is

The first iteration of an XP project should aim to be a BridgeThread : an end-to-end application, which does not have to contain much significant functionality, but from which the rest of the system can be hung. The BridgeThread determines the system architecture. In this XP works much like a weaving spider

Bridge Thread

The bridge thread tries to answer a question that is posed very often and I do hesitate to give an more specific answer than: “Just pick ANY, it will be a long effort to build this product and in X months, what does it matter with what we started”.

The idea of the bridge thread tries to answer the same question. Some ideas (far from complete) regarding the Bridge Thread

• Make sure it is as independent as you can from other stories. It is the beginning, so one of the primary concerns, even more than in later sprints is: Deliver something.
• Make it a core functionality for your product. If you write a app that helps you getting a cab in a city: Do not make it the login. Try to be as close to the part that delivers the value to the customer as possible. Most likely login is not your main business case. (I have advised otherwise in the past … I changed my mind)
• Don’t take any shortcuts. Use a small story, but implement it completely
• Don’t sweat it . It is sprint 1. Getting shit done is more important than getting a lot of shit one. Not producing any bullshit is even more important
• You will have to set up a lot of stuff: CI, automated tests etc. Did I vote for a small Story already?
• All layers included. use a story that needs all layers of your architecture.
• Your estimates are most likely not really good in the beginning. You could pull a story, implement it and pull the next one. Story by story. This is how a Kanban team could approach such a problem.
• Don’t commit to a sprint goal .. just try. There is no real way to commit to something you don’t know.
• Have everything extra-ready. All assets. Maybe a DB design. Architecture? You should have a good Idea of this. As much as I love emergent Architecture and Design, just don’t try always when the last responsible moment for that is. One or two extra hours invested wont hurt. Beforehand the sprint. Not 20 minutes before you start the story.
• Try to hammer a estimate in SP on the Bridge Thread anyways. And Re-Estimate in later sprints. This way you can make sure, that the learning, that took place in the first sprint lands in later sprints.

Do you have more hints what to choose for starters in bigger “Projects” or at the beginning of a new Product or Codebase? Please share them below.

Blog Posts will be moved.

I will be moving some of the posts from here to a new site that will host dissident trainings and all workshop related stuff.

If someone has ideas on the final jekyll site or a way to move posts from wordpress.com to a new blog (my seo friends): please send me ideas and hints.

The posts that will be moved get a tag: ‘dissent‘