Rothi's Blog

There is an enormous hype on everything you might call "immersive technologies" these days, that is virtual reality (VR), augmented reality (AR) and the artificial word invented by Microsoft mixed reality (MR). People outside tend to throw it all into one bucket: It's those weird people wearing even more weird things on their heads. And often this odd feeling may already nourish first reactions of rejection. I am not an exception here. For me personally, I find all those VR headsets frightening. I don't want to wear a black box on my head where I can't see the real world anymore. So I tend to shy away from VR generally. Last week I brought myself to wearing my first VR device: A simple DayDream together with a DayDream certified mobile. It was a blast, I really liked it. Still I prefer to see "what's around me" in the real world.  This seems to be so important to me that I don't shy away from wearing the chunky HoloLens - because I can see

As an agile coach I am often confronted with an odd folk named "software architects". Actually I have been one of those guys for a long time myself. I just had an interview where a group of my current company wanted to hire me as a co-architect. Feeling honored on the one hand I still couldn't really explain an annoying feeling on the other hand. Something was disturbing me and I tried to get a grasp on it. I noticed I'm in constant struggle with these architects since I began to breathe agile air. So why is that, what is really behind this sudden resentment towards the job title "architect"?  Is the architect outdated in an agile world? Should we get rid of them? I say "yes" (just to do some shocking).  But does that mean that in an agile world there's no place for architecture? Of course not. That would be silly. Even if we claim that software architecture should be evolving out of the teams and that means along stories or epics it

My current project consists of an old .NET 2.0 application running on a 32 bit environment and was developed in 2007. The customer works in medical solutions thus underlying some strict rules on behalf of technology and frameworks being used. The software has to run through a special auditing process following some special rules defined for medical software. This is mainly the reason why it's never been ported to a newer version of .NET before. At the end of this year the customer will change his IT landscape though and switch over to x64 systems. x86 will no longer be supported. Therefore I was asked to do some sort of evaluation or assessment whether the old software will run in an x64 environment smoothely and which steps have to be made. Let's put the thing that struck me most first: Thinking back to the old days in 2007 I still can remember what was state of the art in .NET at these days. One could have started a WPF application already but perhaps that was to early for

In our current project we try to use the MOQ framework in order to mock away database accesss in our business logic tests. I was testing some business logic where the executed method would compare different objects and aggregations of objects with each other in order to behave one way or the other. The method builds intersections of collections using the Except extension method and stores intermediate values in lists using the Equals method. Some first tests were successful where the database wasn't mocked. Introducing mocks made me bang my head on the table because of two reasons at least: Getting used to the "over-Lambda'd" syntax of MOQ and trying to guess what was really meant on the MOQ QuickStart page . The documentation is rather sparse and a lot guess work and learning-by-pain seems to be the best way to get along. At least after some time you get along with the syntax and even start to like it. Lists don't behave like they behaved before. WTF! Compare

On my current project I try to learn new web technologies: HTML5, CSS3, JavaScript, jQuery etc. When dealing with the different versions of JavaScript-libraries I hit " git " the first time. Almost any library seems to be published using GitHub nowadays. Since we needed a VCS I had the option to take the old Subversion and deal with that system or try the new Git system. Reading about it I was getting more and more curious about it. I liked the idea about a repository on the internet like GitHub , which would give us the opportunity to work in shared teams. So I installed git for testing and made my first tries. After several hours of trying to get connected to GitHub I had to abandon this. I was (and am still) very disappointed: Of course I'm behind a firewall, of course we use a proxy at the company I work at. I tried different hacks about telling git the proxy server etc. Which is by the way a very bad solution since this is stored in a file on your home directory ca

I'm writing this blog entry after my experience when trying to set up a scrum-like process at my current company. I recently stopped my efforts and want to discuss with you how you estimate: When is the time you must admit you failed or simply when is the time to stop fighting? But back to history: After some painful project failures last year I enganged a little bit into agile software development and read a lot. Like many others I was immediately fascinated by the idea and concept (and I am still). So my boss asked me to take four colleagues for three months to evaluate different processes and develop a software development process fitting our department and company. We developed what's called a "Scrumbut" - Scrum with some adoptions to local structures and a little bit of more focus on planning than in "classic Scrum". Well done, we reached our goal at the end of March and then were heading for the first project to show how the process works. I was enga