Crude Java and Agile thoughts
Category Archives: Agile
Nowadays Agile is almost on its peak of popularity, and Scrum is on everybody’s tongue. I see Scrum being followed almost everywhere. I even came through videos where kids were using Scrum to manage their tasks. I see small/big projects using Scrum to deliver quick and superior products. I see questions and curiosity about Scrum. There are groups where people discuss, share their Scrum pain points and other areas of improvement.
However, Distributed Scrum definitely not as easy as plain Scrum is. It involves geographical, cultural and chronological issues. It has its own set of rules. To have a successful distributed Scrum team is not at all a piece of cake. Read more of this post
I recently did an experiment by designing using CRC cards. I did with my team and found it quiet useful and comfortable. The design outcome of this process was also the team’s design rather than one person’s design. Also, as everyone participated in the designing the design was better than a single person’s design. Please read the complete blog on my official blog site and share your thoughts.
Recently I experimented with pair programming by using two keyboards, one for driver and another for navigator. I was amazed by its out comings. It made programming fun and the code quality, design as well as the productivity increased. I have written the complete blog on my official blog site. Looking at the comments I got on that blog, I assume that people using two keyboards really like this technique. I think its high time we should change the definition of pair programming by adding a clause of using two keyboards. Referring to one of the comments I got on the blog “Pair programming was evolved much before the evolution of usb drives, so using two keyboards was not an option at that time”. Please read the complete blog and share your thoughts. Thank you.
You will often find people in Agile teams cribbing about the overload of meetings. Initially I also cribbed. Then, with time I became more “Agile” and then thought “communication is a key feature” of Agile. I tried to attend meetings with interest. However, I always tend to return towards cribbing about “Overload of meetings”.
So, I thought that there must be something wrong in my interest towards meetings.
The irony was, I always attended other non project meetings with great enthusiasm and participation. So, I tried to capture the impulsive moments of boredom in meetings when I my interest drifts away from the subject.
One of the major points was beginning of discussion on topics which were not planned for the meeting. So, in this scenario, you expect one thing and the result is something else. So, if you are not prepared for what is being discussed, you will feel isolated and get into your own world. Read more of this post
My tryst with TDD (Test Driven Development) started around 2 years back, when my tech lead told me to try to code this way. The first feeling was of shock. I admired my lead a lot due to his immense technical capability. So, this process centric stuff didn’t suited his style of work. Most of the time he gave us all freedom to do a job. So, he specifying a process to write code looked a bit confusing to me.
However, I tried to follow his advice (guideline ;)), at least few times, but never found anything fruitful from it. Those days I was using Agile but not Extreme Programming. So, the tryst with TDD didn’t lasted long as I was never able to utilize it judiciously. The end result of following this practice was not coming clear to me.
Later, I changed my company. The new (present) company was a veteran in Agile and Extreme Programming methodologies/practices. So, I learned to pair program. Learned to re factor. Learned to not do the complete designing at once. Learned to do upfront designing.
Here the emphasis on junit test writing was enormous . So, I sharpened my skills on junit test writing and after a while, I was able to write junit tests pretty easily.
Have you ever been part of/witnessed a team trying desperately to adopt Agile, and the more they tried to adapt it, more hellish their life became ?
I have seen agile adoption failures. And what I have learned from that experience is, that the problem was not Agile. The problem was the way, the processes through which they were adapting it.
The idea of writing this blog originated when I attended the Certified Scrum Master Training few days back. Apart from my colleagues, who are Agile specialists, and really young for this course, I didn’t find any veterans at all. Other than that, most of the people were quiet experienced PMP certified core project managers. These experienced people, who have been working in a completely different environment, following a king-slave sort of process with engineers had become too rigid with time to be mould in Agile. Read more of this post
I have been working in Agile Scrum teams all my career. I have worked in scrum teams sizes of two, three, four, eight, twelve and twenty. I have even worked in geographically distributed teams. It has been quiet an experience to work in teams of these flavor.
The team dynamics basically decided the team’s productivity. Here we measure productivity by the number of user stories burnt, the health of the code, the distribution of business/technical knowledge among the team members, the ease with which the team works with each other and the inverse of amount of discussion that happens before implementing things.
Larger Team Size
While working with teams of sizes greater than four-five, I found out that it was quiet difficult for every developer in the team to know about all the code written. This is a great drawback in Agile teams. Generally there is no or very little documentation about the architecture/design of the code.
Well, agile strictly says no to changing sprint backlog in middle of the sprint. However, I have faced and seen situations where changing sprint backlog looked really logical to me.
The customer builds the product for selling. It’s not showcase of a perfectly modularized, architect-ed, unit tested and agile followed product. Its build for creating money, apart from other reasons like showing the creativity of the thoughts of the product owner.
I have been writing Junits for a while. Sometimes I feel proud of my junit tests as they really look meaningful. However, sometimes the junit tests look so ugly and pointless. I relate this difference to the Abstraction of the code.
Lets talk about abstraction first. Abstraction is generally governed by “separation of concerns”. Each unit of code should have a separate responsibility. These components are later integrated to perform certain functionality. So, if these separate components are tested separately, then its tested that each component is working perfectly.
Don’t confuse abstract with abstract keyword in java.
If a class is truly Abstract, then it handles only one responsibility. The sole purpose of the class is to perform a function which can not be broken down further into more non-trivial functions. In a junit test class for a truly abstract component (class), the test cases will be dedicated to test a fine grained module. So, it will be easier to concentrate on the functionality and more test scenarios cases can be thought upon.
This in turn increases the meaningfulness of the test code. The test case doesn’t need to bother about behavior of the dependencies. This will automatically decrease the time taken to write junit test cases.
Read more of this post
Unlike most of the people writing on Agile, I have only two and a half years of experience in software development. But that’s not the only unlikeness, unlike most of them, who were born in “The waterfall era”, when I was born in software industry, Agile was already quiet famous, and that’s the only software development process that I have worked upon. So, I am completely unbiased towards waterfall, I have just read and heard (from senior colleagues , both praises and slangs :)) about it .
I have seen people migrating from different development models in Agile. I have also seen few freshers (like me) being born in Agile era directly. And after a very short interval , almost all of them feel it’s a very comfortable and efficient way of software development. I agree too.
However, when you will read about Agile, re factor and rewrite will accompany it everywhere. Why So?
We all know that change is unavoidable and we must adapt ( so must re factor). But the amount of re factoring done in agile is awful. There has to be some reason behind that and I think its pair programming.
Lets see why I blame the pair programming:
- Generally people don’t think a lot while pair programming as the person who wants to think about the pros and cons will be considered inefficient (as he will slow down the coding speed). So, generally people show fake confidence on the effectiveness of the proposed solution. Some common comments will be (“We will change the code if problem occurs”). The re-factoring tasks generated due to this type of attitude is the outcome of pair programming only as no single person can be held responsible for the mess created.
- One of them suggests solutions very fast, which are always crap, and will always need a reimplementation . His pair has to find the loopholes in the proposed solution in almost no time. If not, he has to go with the proposed solution. (And it’s not necessary that the fastest solution will be the best one).
- Persons having aggressive and inhuman behavior will make their decisions accepted (even if his pair is having a better solution).
When two persons pair, the entire code flow is neither of them, as two persons can not think exactly same things at same time. So, the outcome is a spaghetti of their thoughts which will need re factoring for sure.