Hi all!
Ok, another of the principles done. Just one more D = Dependency Inversion Principal. Again, everyone was happy for me to do the next one. The proposed dates are … November 18th 2009 or November 25th 2009. Please let me know your which is prefered.
We covered the theory behind the principle, then looked at and discussed some examples. We discovered how follow the SRP makes this one much easier to adhere to. Another “principle” YAGNI (you aint gonna need it yet) also plays a part in adhering to the ISP.
Put this principle into high gear when designing frameworks, avoid fat interfaces and apply SRP.
We also decided that in december, we’d still meet, but it would be for a supper, so your suggestions are welcome. We can also use it as a time to plan stuff for the new year, so bring along some ideas on what you’d like to see.
Oh! If anyone wants the slides, code etc - let me know
Thanks!
Zak
Hey !
It seems this is actually going to happen. I’ve booked a spot for Wednesday 13 May 2009,6:30 pm at c’est la vie and seems like we’ve got close to 10 people actually interested in being there. Pop over if you’re in the area.
So what’s it all about ? A couple of us want to get together and “talk dev”, to explore ideas, learn, unlearn and share.
Well if no one turns up, at least they got good food there 
So we’ve all been there. The new project excitement, requirements, saying we learnt from the last failed project. We have agile, scrum, xp, lean etc. So why do we still get failed projects.
A google search on “why software projects fail” reveals around 20,100,000 hits. It does seem like the situation is here to stay. As an industry that works around analysing a problem and finding a solution, can we not fix this ?
What are the key factors that cause projects to fail? This is an open question, so feel free to add to it.
Seems like most lists out there favour the following as key factors…
- Poor requirements
- Poor practices
- Changing requirements
- Lack of understanding requirements
- Lack of ownership.
- Lack of communication
- Lack of knowledge
- programming
- methodologies
- domain
- Lack of planning
To me the success factors seem obvious …
- Requirements - If we understand what’s “poor requirements”, can’t we get better ones?
- Communication - developers, steakholders, project managers, development managers…
- Share knowledge -
- ensure everyone knows the what, why and how.
- Understand the techniques and methodoligies used - not just the words
- collective code ownership : everyone should share responsibility for the quality of the code
This is a recurring problem within our industry, so why can’t we fix this?
