Posts Tagged ‘xp’
5 Missteps when Writing Code
 |
5 Missteps when Writing Code
I’m often asked to look over other people’s code, and these are 5 of my pet peeves rolled into a post. tl;dr: bad documentation, no unit tests, unnecessary optimization, not auditing/logging, too strick adherence to methodology  5 Missteps in Writing Code
Like most developers I am constantly struggling to deliver in the face of unrealistic or extremely tight deadline, which can be self imposed or come from external sources. As I will likely discuss ….
|
 |
5 Missteps in Writing Code
Like most developers I am constantly struggling to deliver in the face of unrealistic or extremely tight deadline, which can be self imposed or come from external sources. As I will likely discuss in a future article this can be due to over optimism or rigid planning in the face of customer demand. It can also be due to missteps which the developer themselves have made. Read the rest of this entry »
Scrum Masters as Sri Ganesha’s pundits #agile #xp
You would probably not associate a god from the Indian pantheon with an Agile methodological, and there are many things that can be learned for Scrum masters from Ganesh.
In Scrum the Scrum Master focuses on 4 key areas:
- remove impediments
- buffer against distracting influences
- enforcer of rules
- focusing team on tasks
Ganesha is the Lord of Obstacles, both material and spiritually. And is worshiped as the remover of obstacles, although he also places obstacles in the path of worshipers. The Scrum Master also removes the impediments and places obstacles in the path of the team members. Ganesha fans his ears constantly to symbolize that often words are spoken, but one is not receiving inside. This is what happens when the length of the meetings is too long, or it digresses off-topic. This is also what the broken tusk is said to symbolize, with oneness of mind and single-minded devotion you can achieve everything. In your team you can keep your focus by focussing the energies on the ability of the team to create results, and allowing the members to achieve.
Image source: Vijay Bandari – Wikipedia, Anamika S
How large is a Two-Pizza Team? #scrum #xp
After reading about 2 pizza teams in Wired UK 03.12, I read that the comment came from Werner Vogels, the Amazon CTO. He says prefers two-pizza teams; “technology teams working on a given project typically can be fed by no more than two pizzas—usually eight or fewer people.” This makes no sense to me, and I’m sure you may find the same.
I can easily eat a 13″ pizza at one sitting. A 13″ pizza has an area of approximately 856.3 cm2, the largest size that Dominos Pizza makes is 16″ with an area of approximately 1297 cm2. This means that I would be full at approximately 66% of the 16″ pizza, when I split it evenly the pizza only feeds two and leaves us both a little hungry.
Read more articles on Agile, SCRUM or XP…
How does Vogels think he can feed up to 8 people with 2 pizzas?
Image source: VirtualErn
Design – Re-Inventing the Wheel #agile #scrum #xp
Everybody tells you not to reinvent the wheel, and I am going to explain why everybody is wrong and you should start re-inventing. Programming paradigms and design patterns are the staple of all new programmers, and they enable everybody to communicate in a common language which can be easily understood when their rules are strictly adhered to. The issue is that beginner developers have cursory knowledge, expertise and familiarity with the design patterns they are required to implement.
A recent practical example a group of relatively inexperienced programmers with the Model-View-Controller paradigm found that the controller they were using didn’t make their life easier, so in some specific cases they deviated from this and implemented their own heuristics. This caused the underlying database to get more SQL queries that even Facebook reports it gets. At the point the website ground to a halt a simple investigation revealed that they bypassed the controller and model to access the database. Common heuristics would usually point to scaling vertically or horizontally.
If it looks like a duck, it walks like a duck, and it quacks like a duck, guess what? It’s a duck.
A Duck?
It is not always a duck. Current thinking is that common things are common, and common problems have common solutions. This isn’t always the case, Henry Ford summed it up best: “If I had asked people what they wanted,” he said, “they would have said a faster horse.” By living in the constraints of their knowledge when people hear hoofbeats, they think horses, not zebras. And “[w]hen faced with a result that doesn’t go according to plan, a series of perfectly effective short-term tactics are used until the desired outcome is achieved.”[2] Some developers believe that once this hurdle has been taken all will be well, I can tell you the light at the end of the tunnel is an oncoming train.[4]
When you are in a hole, stop digging! That is exactly how we got into the mess in the first place.
How do you stop digging?
You have become increasingly convinced of the truth of your misjudgment, developing a psychological commitment to it. You have become wedded to this distorted conclusion.[1] Realizing this is your first victory. “In the material world, the unknown is a place of uncertainty and potential risk … [b]ut we make a mistake when we attribute the same qualities to the world of our thinking.”[3] The second victory is having the courage to throw out everything you have done up to now, baby and bathwater.
“There is a wonderful story of a group of American car executives who went to Japan to see a Japanese assembly line. At the end of the line, the doors were put on the hinges, the same as in America. But something was missing. In the United States, a line worker would take a rubber mallet and tap the edges of the door to ensure that it fit perfectly. In Japan, that job didn’t seem to exist. Confused, the American auto executives asked at what point they made sure the door fit perfectly. Their Japanese guide looked at them and smiled sheepishly. “We make sure it fits when we design it.” In the Japanese auto plant, they didn’t examine the problem and accumulate data to figure out the best solution—they engineered the outcome they wanted from the beginning. If they didn’t achieve their desired outcome, they understood it was because of a decision they made at the start of the process.”[2]
Clean Slate
Read more articles on Agile, SCRUM or XP…
Starting with a clean slate learn to question everything you know and are told, especially what I tell you. Learned heuristics can be good, but they are only as good as your teacher. You own experience is key to be able to implement anything. Having a prototype or an example can help you, and a prototype is only as good as the developer who wrote it. Don’t be afraid to start over rather than refactoring, there is little to lose and everything to gain by ignoring the old paradigm: “If it ain’t broke, don’t fix it.“
- How Doctors Think
– Jerome Groopman, MD
- Start with Why
– Simon Sinek
- Effortless Evolution – Jamie Smart
- Wall Street proverb
Image source: Sebastian Fritzon
Recognizing Signals #scrum #xp #agile #lifehack
Signals come from everywhere, they are tell us something about our environment. Whether it’s hot or cold, wet or dry, and painful or pleasant. These signals are rarely binary, there are gradients in the signals. And we have signals with which we aren’t dealing at that moment, which we’ll call noise in that instance. Feedback is also a signal, perhaps it causes a painful sensation or it causes a pleasant sensation. Whatever the sensation it causes that sensation too is another signal which we can choose to regard as noise.
User Stories: How small is too small? #scrum #xp #agile
I like a User Story to be precise and target a specific functionality, a Use Case or a logical vertical of a Use Case. This means that a finely scoped task of 2 or 3 hours could be called small. It also depends at what time in the SCRUM backlog a certain User Story is implemented for it to be a small or large User Story.
At the beginning of any development project all User Stories are large, they include many additional variables everything from setting up the initial design patterns, to drastic refactoring to allow for stackable functionality. This means that a task which might take 2/3 hours once there is a working vertical to build on could take considerably longer when everything needs to be build from scratch. Ron Jeffries – SCRUM God – says Read the rest of this entry »
Code Review in SCRUM? #xp #agile #mathematics
Recently I was asked by a client to make some estimations regarding a review of a code review for a programming project. The aim of the project is to refactor the existing code for efficiency, check the security and add new functionality. Having done code reviews in the past I had an idea on how it should be done, and little idea on how to quantify the work into an estimate.
How a code review estimate is done now?
Testers in SCRUM? #agile #xp #qa
Testers are very important in SCRUM, before the sprint they help the Product Owner to refine the User Stories are help with “How to Demo” and “Definition of Done”. Doing this during backlog grooming or analysis meetings allows the Testers to suggest User Stories for testing such as in the sidebar, and allows them to product examples which can be used for automated testing, help with sprint planning, among others.
“As a Tester, I want to read a log, so that I can verify that payments have been processed”
During the sprint, while programmers will be implementing the functionality, the testers will be implementing manual test scripts, automated tests and acceptance tests associated with the user story. In some places they develop the automated tests paired with a programmer, and in others they script the tests themselves. The testers would deliver “Running Tested Features”, preferably together with the programmer, which comply with the Definition of Done which the Product Owner, Testers and Team have defined.
Read more articles on Agile, SCRUM or XP…
You can see that Testers are a vital part of any SCRUM team.
Image source: Wikipedia
Sources: Lance Walton, Henrik Kniberg
Why Re-estimate User Stories? #scrum #agile #xp
On the SCRUM Development list two questions often pop up, I call them the why and when of re-estimating. There are few defined rules on re-estimating, yet estimating and re-estimating is an important part of backlog grooming. Which is why this is a recurring question in many SCRUM fora.
General Musing 