Git is magic, but sometimes it drives my crazy with all that power causing strange situations and clean-up work. The magic of git is that it is (nearly?) always possible to clean up the mess and get back to a good state. The problem is that there are A LOT of commands to master. This post is a story about cleaning up a pull request to prepare it for merging into master.
The pull request contains functionality that I do want to merge, but also workarounds for cultural sensitive unit tests that are obsolete and should not be merged. There’s also a rebase that has been done in the wrong way and a merge from master of the forked repo – which is no longer in sync with the main repo’s master branch.
Nowadays everyone is agile. Or at least they say. Most organisations use Scrum. Or they claim to do it, while still doing waterfall. But why is the industry so focused on Scrum? What happened to eXtreme Programming? Why did we loose the XP practices? Are they too extreme?
The first agile methodology I heard of was eXtreme Programming back in 2001 when I was a CS student and read the eXtreme Programming Explained book by Kent Beck (published 1999). I remember reading about the ideas of pair programming, refactoring, test driven development and simple/evolutionary design and thinking that this is the future. The planning game and user story for requirements parts was nothing I payed that much attention to – I was completely focused on the code writing at that time.
Scrum is a few years older than XP, being launched in 1995 by Jeff Sutherland and Ken Schwaber. If you’re a regular reader of my blog you know that I have thought and written quite a lot about Scrum but very little about XP. The reason is that I’ve been quite focused on the management view of agile projects in order to get the customer interaction working. While XP is a bit vague (and too extreme with a customer full time on the team), Scrum offers a set of rules that is easy to get started with and easy to explain to the customer.
I think that I’m not the only one being dragged to Scrum because of the relative ease of getting started combined with the focus on the relation with the customer. Add to that the fact that most managers that are involved in methodology selection understand the core Scrum process, but without a strong foundation in development most XP practices make no sense. From a “marketing to management” perspective Scrum is easier to argue for and has become the de facto standard agile methodology.
But I think that we lost something along the way. We lost the technical XP practices that are an important foundation for the ability to be agile. Without those technical practices, can a Scrum team really become truly agile?
Watching the Build Keynote it is clear that the “Modern” style of applications are here to stay. The desktop is now legacy. For the consumer market it is already happening as new PCs with Windows 8 are sold. For businesses, it is more complicated since many businesses are still on Windows 7 (or even deploying Win7 right now to replace WinXP).
I’m writing this right after having watched the Build keynote (quick text overview by Iris), but I’ve really thought of it since I helped my parents with their new laptop a month ago. My parents are not tech people, but they know how to use a computer. They’ve got a new laptop with Windows 8 and to be honest, they are quite confused. The new modern start screen is great for them – except that it lacks key program packages such as Office.
But now that’s changing. Microsoft is creating a new touch first Office experience, that will be based on the WinRT runtime. With that installed, my parents will never look back to the legacy desktop any more. They will have everything they need in the modern start screen. The desktop will be for legacy, non-desktop applications. Just like the MS-DOS prompt available in Windows 3.1 was a way to run legacy DOS applications in the “old” interface.
This is a guest post from Håkan Rudelius. I’ve been working with Håkan for the last few months at Com Hem (Sweden’s major cable operator) and the discussions with him have been a great inspiration for me on agile, lean and team building.
A friend of mine, Jan, who is consulting at a major telecom company came up with a real nifty idea for how to make documenting smooth and well, almost – fun…
You recall how it’s normally done, right? One poor team member has to “volunteer” to the far from glorious mission of updating the system documentation to reflect the system updates that the team made in the sprint. So the poor guy has to write down everything he knows and then walk around and interview the rest of the team to get everything right. This task normally takes longer than expected because:
- It’s so boring so you take every opportunity to get distracted.
You go get yet another cup of coffee.
You join a discussion between fellow developers.
You check that interesting website about nhibernate.
And so on
- The person you need to interview is busy.
Once the document is updated, you normally have to have at least one boring review meeting to get everything right.
So in order to get around these problems my friend decided to try “team documenting” or “mob documenting”.
I’m honoured to have two sessions approved for NDC 2014 in Oslo in June. I’ll be talking on “Strangling the Legacy out of an Application” and “Using the Scrum Rules Against your Boss”.
If you are a frequent reader of my blog you know that diving deep into the code and using agile methods are two of areas that I’m interested in. Now I’ll have the opportunity to not only write about it and also talk about it. I have to confess though that I’m a bit nervous. I’m doing the strangling talk right after the opening keynote on the first day of the conference. The scrum talk is at the very last slot of the conference on Friday, in a room that will house scrum talks by Mike Cohn all day before it’s my turn.
Using the Scrum Rules Against your Boss
Managers think that Scrum was invented to make developers work harder. That’s a lie. Scrum was invented by developers to keep managers away so that developers get time to do actual work.
Learn how the Scrum rules can be used against your boss to get a realistic workload and more coding time without interruptions.
Strangling the Legacy out of an Application
A ten year old system with a basic architecture from a distant past (.NET 1.0? VB6?). New functionality built throughout the years with the then state of the art technology. On top of that some cosmetics to make the web interface look modern, but in reality the application is rotten on the inside and about to fall apart any day. That’s a common work environment for many developers.
But there is a way to get out of it without funding for a complete rewrite. Anders shares his experiences on strangling, a method where a new architecture is built in and around the existing code based, gradually replacing the old rotten code with a shiny new architecture.