Do you worry about crappy code? Then face reality and grow up.
Posted by Serge Beaumont around lunchtime: April 24th, 2009
My colleague Age pointed me at a blog post by Uncle Bob about a presentation where a Mr. Josuttis presented the inevitability of crappy code because "businesses will do whatever it takes to cut costs and increase revenue, and therefore businesses will drive software quality inexorably downward". Uncle Bob proceeds to go against that argument, but I find it to be a technocratic (DSLs and produce better code) and ultimately unsatisfying answer. My answer to the problem?
Face reality, grow up.
Recipe for slightly burned decisions
Posted by Barre Dijkstra in the early afternoon: January 28th, 2009
This recipe describes the process of baking marvellous, slightly burned decisions. If you’re looking for the well-done version of decisions, I would suggest altering this recipe by adding things like “necessity”, “timing”, “context” and “feeling” or taking another recipe on the subject.
(more...)
Team Dynamics – what to expect and do?
Posted by Abhishek Agrawal in the early morning: October 15th, 2008
Effective teamwork is essential in today’s world, but as you’ll know from the teams you have led or belonged to, you can’t expect a new team to perform exceptionally from the very outset. Team formation takes time, and usually follows some easily recognizable stages, as the team journeys from being a group of strangers to becoming united team with a common goal.
As part of my curriculum of “Leadership Training for Software Professionals” at IIM, Bangalore, I came across some very interesting and highly applicable models explaining various stages of team dynamics. It also laid out what we, as managers, should do/expect at various stages of the team maturity.
(more...)
Agile Maintenance – One Team Multiple Projects
Posted by ShriKant Vashishtha in the early evening: August 21st, 2008
You may land up in situations when a project is almost stable. For developers handling issues and enhancements for the project, the work available is not sufficient. So, when team is comfortable with the project and it's already stabilized, team can start handling another project at the same time. It's good for the people working in these projects from learning perspective. They are exposed to multiple technology stacks, problems and functionality. At the same time, it works well for an organization in general.
(more...)
Agile (tools) for the enterprise?
Posted by Barre Dijkstra in the early evening: August 13th, 2008
I was speaking with a colleague today who's working as a scrum master on a project with another customer. While we were discussing on how we both look at project metrics and related subjects, the subject of tooling was touched. They used ScrumWorks at that project and were quite happy with it.
After walking through the tool and specifically the features that dealt with organising releases, projects, etc. I found the tool lacking on one part, like all the others I've seen and/or evaluated; My current client is an enterprise organisation that has hundreds of employees that work on the software development, due to control of the environment works with fixed date releases and has multiple programs and projects running simultaneously.
(more...)
Commitment
Posted by Erwin van der Koogh mid-afternoon: July 18th, 2008
A few weeks ago I was asked to explain Scrum and how our Agile Offshore Delivery Model works to one of our new sales guys.
During the session he asked me the question: "What does a client have to do to make a project done this way successful?"
Back to the 80’s…
Posted by Twan van Enckevort in the early afternoon: July 15th, 2008
One of the challenges we are facing in our project is connecting antique display devices to the brand new travel information system we are building. If you have traveled by train in the Netherlands you are familiar with them: large displays with booklets for destinations and departure times. It contains a number of booklets which are controlled by a stepper engine. The devices are called CTA's, were developed in the eighties and are a solid piece of engineering. Behind the track indicator, which doubles as a door, is a temperature control for the heating, a power socket for connecting electrical equipment, a telephone socket and a connector for testing. Oh yes, did I mention it is heavy?
How to manage Scrum and the Loaner Specialist
Posted by Eelco Gravendeel just before lunchtime: July 11th, 2008
Multidisciplinary teams are fine and all that, but how to go about true specialists in the project … where do they fit in? I would like to talk a bit about Specialists who are required to do work for the team, but do not have enough tasks or time to actually be part of the team. First I will show why it is just not practical or feasible to make some people fulltime team members. After that I will drop some ideas on how to handle these situations.
Top 10 SOA Pitfalls: #2 – Unclear ownership / Project based funding
Posted by Viktor Grgic in the late afternoon: June 16th, 2008
Last week Viktor Grgic explained the Missing skills en this week we’ll continue with #2 - Unclear ownership / Project based funding
In the world of standalone applications, there is typically a clear sponsorship and ownership of an application. There is also a single project with one project manager. The systems could be small or big, but the pattern remains the same. Funding is based on a business case and can be easily defended.
In SOA world, the story is different. There are the usual projects, each having their own objectives and often reluctant to work on generic services or enterprise components. If the ownership and funding for these components and aspects are unclear then chances are high that nothing happens on enterprise level or that it's not according to enterprise architecture or nobody feels responsible when things on enterprise level go wrong (e.g. security).
Several projects working together is not a bad situation, but there should also be a SOA steering committee and SOA competence center well funded and supported by company board.
(more...)
Agile way of documentation!!!
Posted by ShriKant Vashishtha in the late afternoon: May 5th, 2008
As you enter into Agile world, a statement welcomes you - "Just do enough documentation". For quite sometime, I was puzzled what we really mean by this. In my view "just-enough" is very ambiguous or abstract. You cannot quantify it. For some who are working for a development project, creating documentation may not make much sense as you can find people just across your table to answer your question and you can get away by doing "not just-enough documentation" (no java-docs, no project overview etc). However when you come in maintenance cycle of the project, it just sucks. Maintenance may implicitly means new people, a long project cycle and people who leave the project or even organization itself.
What do you do then? People who were in the project at the beginning may not be there anymore, either from customer side or from software developers side. Without having a knowledge repository, new people will try to reinvent the wheel, will go through the code (white box, which ideally should be a black box most of the times) or will look like people who enter in a dark tunnel without having clue on what they are supposed to do.
Archives
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)