The Road to an Agile Project – Visualize!

Hello and welcome back! In this series of posts I am trying to give other teams of developers out there some path to embracing agile methodologies, such as Scrum. Previously, in my Prequel post, I described how you could start doing regular standup meetings in any type of project to increase your teams awareness about each member’s work.

Assuming your team has now incorporated standup meetings, preferably on a daily basis, it is time to take the next step. Agile methodologies generally rely on a rather simple notice: Visualized Management! Now don’t get scared, the word ‘Management’ here does not mean you need another manager. When done right, this visualization can eliminate the need for a manager. Now doesn’t that sound sweet? 🙂

Continue reading

The Road to an Agile Project – The Prequel

Well hullo there! It has been quite some time since my last post. A lot has happened recently, some of which prevented me from posting regularly. Let’s just blame the current economic conditions for that.

Since my last post, we have pretty much finished our JavaFX project. I was at the NLJUG’s JFall where I hosted a JavaFX workshop all afternoon and I have been to Devoxx in Antwerp where I met Richard Bair and Jasper Potts from the Oracle JavaFX team.

I have also joined Stephen Chin in the maintenance of the Visage language. This is the continuation of the JavaFX Script language as an open source project (see Google Code).

Now shut it, you mentioned something about agile…

Continue reading

Enterprises waste money with architects…

This in itself is no news obviously. The bigger an enterprise gets, the more likely it is to waste money due to the introduction of management layers and function decomposition. What is function decomposition you ask? I am not sure it is a proper business term, but in programming languages it is defining the value of a function as the value of other functions. This can generally be done over multiple levels and potentially create an infinite loop.

When you perform function decomposition, you create a set of dependencies between these functions. The original function’s value will now be defined as the result of the entire chain of underlying functions. The problem with this is that it is hard to maintain the exact definition of the original function if that of any of the others changes. I.e. it is becoming hard to ensure the correctness of the first function.

Additionally, the functions in the ‘middle’ of the decomposition chain originally have no meaning, except to the first function that calls them. After all, they are responsible for performing part of its task. The risk that rises from this decomposition is the fact that these functions may eventually be used elsewhere and because of that require slightly different functionality. Does this influence the first function?

Okay, enough theoretical babble, what does this have to do with enterprises wasting money? Continue reading