Sharing common values with people in organisations help to build and implement good practice. Without shared common values it can be impossible to agree on many things and this is one of the biggest obstacles to climb when forming a team or joining an organisation.
In my experience, common values can take a lot of time to align. One method to align them is build rapport and trust but this often takes time, perhaps a more rapid approach might be to find a mutually respected source where values can be justified and interpreted by a third party.
Industrial XP tells us that our team should discuss their values and come to a consensus. I believe that this is achievable in an environment where a foundation of trust and rapport exist.
When an organisation is growing or the structure is changing, trust and respect take time to be built. I have noticed, that discussing values at this time can fuel argument over interpretation of various personal values and distract from the objective. Getting all parties singing from the same hymn sheet.
I believe that by using carefully selected prescribed values it can be possible for a team to embrace those values and build rapport through them.
The following is an example of values as defined in Extreme Programming Explained by Kent Beck.
This particular set of value are very general and leave lots of room for interpretation. I believe in most circumstances this is a good thing. When complimented with Lean and Agile philosophy the chances of misinterpretation or negative outcome are significantly reduced.
Once these values are accepted as useful guidance and not laws the real improvements can begin, and we are ready to embrace change..
We all find it difficult to communicate our feelings, more so when working with complex problems everyday. Bottling up these feelings takes immense mental strength and patience, burdening other aspects of your life. I have found that by developing your courage you can focus those efforts more effectively. If, like me, you identify with this problem read this
Awareness of these principles across a team increases cohesion.
More to come.
Agile customer proxy is interesting.
Surely nothing is wrong…
In 1995, it reported that only 16.2% of software projects succeeded. In large companies, the number was only 8%. That is, these projects were on time and on budget.
The 2012 report is still fairly damning of the industry as a whole. It cites 12% success rate for waterfall projects and 42% success rates for agile projects. Firms like Headspring, with a 95% success rate, have embraced agile, of course, but there is still so much more to be desired by the track record of the industry. In 2012, 9% of agile projects still out-right fail, and 49% are “challenged”. i.e. they unacceptably ran over budget and/or over schedule
OK, so maybe there is something wrong.“If cars were like software”
- Over Promising Estimations
“you simply don’t KNOW whether something is possible yet without research into it”
“Managers and sales guys can be really annoying; understandably, they have to tell THEIR employers what’s up in the development process and where we are. But if you give in and avoid disappointing them now, you will only disappoint them more later.”
- Lack of good requirements
- Budget constraints
- Unreal expectations
- over-ambitious goals
- feature creep
- (most likely), under-investment
So what can I do about it?
Build awareness so everyone can work together to solve this problem early.
“I assume you know how to put together a jigsaw puzzle, for nearly any 3 year old can put together the most basic ones.
So let me ask you a question. If I went out and bought 5 jigsaw puzzles, each with say 2,500 interlocking pieces, how long would it take you to put together anyone of them?
Can you tell me within 25% of the actual time how long it will take you? After all, you DO know how to put together a puzzle, right? And it you can do that, can you tell me what day you’ll have all 5 of them finished?
I want to know! And can you have your reply ready for me by 3pm today?”
Deal with misconceptions. We are not building cars we are designing them.
What we need to do is get businesses to understand that when they undertake to have custom software built, what they are really asking for is not a construction project, but an R&D project.
Don’t ignore aspects of the business to give the illusion of agility.
Agile can improve things, but I have found that for most businesses, no matter how much you communicate that requirements need to be flexible, that you charge hourly for time spent, that adding things increases time and costs, at the end of the day they still expect to be billed exactly X dollars after X months for their exact scope, even if that scope exists entirely in their own minds.
We have a lot to improve upon in our industry (education in patterns, solid principles, db techniques, soft skills, requirements gathering)
Make sure not to build in bad practice
I used to work for a company, which was making about 3x more money from supporting crappy projects they have built for 1x at the first place. That’s what happens when none of the stakeholders is anything close to technically literate.
When object orientation was applied to relational data this was the outcome over the last 20 years.
2000 Java data objects
2005 n Hibernate
2007 .NET 3.5 with LINQ
2008 Entity Framework and Sub Sonic
2010 .NET 4 and Entity Framework v4 capable of working with Stored Procedures
What is a Object Relational Mapper(ORM)?
It is a tool like any other in software which solves the problem of how to get real world objects which can have massive complexity into a relational table structure. This would normally be considered by a developer upfront when they are creating a feature and is subject to fragility and assumption.
If a developer has a good grasp of good database design and practice. Then using an ORM can be very worrying because manipulating data has always been done as close to it as possible to maximise efficiency. Typical concerns are security, re-usability, performance, maintainability, and supporting a live application.
All of these concerns are addressed by ORM. But if you have massive amounts of business logic and conditions in SQL Stored Procedures it wouldn’t make sense to move it because then you are exchanging a bunch of trade-offs for another bunch of different trade-offs. However it is my understanding that where feasible in a project supporting the use of an ORM. The reduction in time spend writing plumbing code, more than makes up for the issue of reverse engineering domain logic from T-SQL and re-engineering it. It also presents an opportunity for assumptions and misunderstandings to be clarified with the domain experts making more developers better domain experts. With the added bonus of distributing project knowledge across the team enhancing flexibility in times of added constraints.
Let’s consider the fact that you’re more prone to mistakes when you limit yourself to one way of doing things. Perhaps there is a case for any business to try something purely because it is an alternative. Also the fact that the more code in a project the less maintainable the project will become, implying, code reduction is crucial to return on investment.
If you are using stored procedures, or reusing them over multiple projects you owe it to the business to give Object Relational Mapping a punt.
As shown above ORMs are a very recent development and the subject of controversy due to their perceived ignorance of database design. It is true they are powerful but as with all powerful things they should be used with a measure of caution and understanding.
This is quick reference material.