Continuous Collaboration with Mingle, SVN, Email and Wiki – Part 1 (Forming)


Agile has been around for sometime now. Most use it as a buzz word, not benefiting from its core principles people maturity and and need to extreme communication. This development life cycle is initiated by developers essentially. Think about it. All that CMMi gives you, is a top bottom approach. And since the acceptance of the young generation to agile is just so high, CMMi has to give way. So they just “accept” what you say, and today CMMi is just a certificate with very less value with the young generation.

Obviously just like PMI, CMMi is struggling to prove its point today. That processes are important and if not done the CMMi or PMI way, will fall flat. The fact remains that organizations with PMI and CMMi are falling flat. They no longer do the amount of software development they use to. They now focus their business on “servicing” software products already developed. Basically they could not keep up with the pace. Not their fault in my opinion, just that the pace is too fast for anyone to keep up.

It needs you to think that you are “worthless”, and start studying again. Pick up your database book, design patterns book and programming language book and start writing some code, debuggers, watch’s. Get your head out of excel sheets, ppts and mpp’s :). It is when you dont get your head out and start studying, you realize that you cannot keep up with the pace. And start believing that without CMMi and PMI projects cannot run. Until you get a rude wake up call by a young engineer (but considering the youngsters today, I dont think they care about wasting their time with you). So guys/gals wake up. Get your head out, and into the right things.

So what has this got to do with Continuous Collaboration. Well, everything.

The above was a wake up call for you to realize that today running projects is about collaboration. As a manager if you frequently think, “if the Iteration Manager/Business Analyst will do this, what will I do”, its time for you to wake up (read the first few para’s).

You have to do some real contribution. Martin Flower says it. Write some code (gain respect of your fellow’s). Create a framework that can replace and refactor some dirty code. Reproduce some bugs, play with the interim builds of the product and give valuable feedback. Dont need your tech leads to sit thru all meetings to give feedback to UX. In other words do some real contribution. Ask relevant questions, effectively communicating with lesser words and more diagrams. Do some tech talks. Show them that analytical ability only increases with time and age, and not the other way around.

Strategy Pattern (Initial thoughts on a Client Server architecture)


Any client server application needs to pass requests and await responses between the client and server. Use of the Strategy Pattern, can do a good job here. So, I am thinking, keep the code neat, encaptulate the request code, request data and response processing in just one class. Abstract the server from adding, modifying new requests from client. Obvious benefit, the server need not be modified for new requests added by the client, and multiple developers working on the client code.

Anyone want to take up the challenge of designing such a architecture ?

Ever think, which design pattern was most used OR even better, should I use an abstract class or an interface ?


Busy with relocation, just got my internet connection working :).

One interesting topic I always wanted to read on the net was about which design patterns are the most famous and I wanted to avoid discussions and articles that have “depends on situation”. I just cant accept that answer, depends.. :). So here is my take on last 6 years of its use.

Strategy pattern is the most used. Yeah! Yeah! you will argue on the MVC, but come on have you actually implemented the MVC, no you haven’t in true sense. What you have implemented is the MV model, not the C. You may have used the MVC implemented by frameworks right? So don’t give me that argument. And yes, don’t even start about the Singleton, if you have used it, you will know the lesser you have and lesser you need pattern in a product. I mean how many singleton’s can you or will you or should you have in an application right ?

Strategy for me is fantastic use of future growth, re-usability and abstraction. The question that I had was, is it better to use an interface or an abstract class when implementing the Strategy pattern? The answer is simple, if you have future growth needs for your customizable design, you will most definitely have come common behaviour for each of those who are sharing the signature, so use of interface is lame. I would always use an abstract class. Now lets see you debate that.. 🙂 Comments please.