XP is a “software development through the eyes of an engineer” kind of methodology. It focuses heavily on engineering practices.
On contrary, neither Scrum nor Kanban seems to care much about best software development practices. But wait, if you read about Kanban a bit you’ll quickly find an advice to focus on your engineering practices too as Kanban (or Scrum) alone is not enough.
Actually I can’t recall any project management approach which says “when it comes to code, do whatever – this whole programming thing doesn’t really matter.”
So we’re back here again – a set of best software development practices is important. Yet, there is plenty of them, how to choose the right ones?
You may choose a set of tools you believe are most valuable. However if you don’t have comfort of choosing toolbox first and then looking for people who are familiar with tools (or at least willing to learn how to wield them) you’re likely to fail.
Every change is difficult and developers tend to be pretty stubborn. Yes, they will do this whole code review if they really have to, what a big deal anyway, but don’t expect to get decent results unless developers believe it is a valuable technique. They will hate it probably as much as filling data in time tracking app, which isn’t even close to what you wanted to achieve, right?
And this brings me to another approach: let engineers choose which engineering practices they want to employ. Let them argue. Let them look for consensus. Help them in facilitating discussion if it’s necessary but don’t enforce any specific technique. Throw in a few ideas but if they don’t catch up don’t try to use your magic power: “I can force you to do so.” If you’re a team leader or (even worse) a manager it’s not you who will be doing this darn thing every single day for next couple of years so just shut up, OK?
The best set of engineering practices is the one which will be adopted by engineers. And yes, this means it will be changing over time. The more mature the team is the more practices people are able to adopt.
The same rule works in other areas too. Product management? Well, don’t you have a product owner or something? Let her decide. Testing procedures? Shouldn’t you agree to whatever your QA guys want?
When it comes to discussion on standards a manager should take a step back and let a decision to be made by people who will be affected.
There’s one trick here however. If you happen to work with inexperienced or just average people the consensus may be “let’s just hack some code instead of wasting time on this stuff, we’re Cowboy Coding Wizards and nothing can beat our code.” But then you have a bigger problem than deciding which of best practices your team would use. You better start to evangelize your team a bit or look for another job, whichever looks easier.
There’s another trick too. What to do if you have hundreds or thousands of developers? Well, different toolboxes should emerge in different teams and it would be pretty stupid to try to standardize all of them. “What if nothing emerges despite a multiple teams working on software development?” you may ask. Well, running away while screaming would be a pretty good option there I guess.
You didn’t really expect to see here The Big List of the Best Engineering Practices Every Team Should Adopt, do you?
Subscribe RSS feed
Follow on Twitter
Subscribe by email
6 comments… add one
Pawel, good points. I picked up on the line: “Testing procedures? Shouldn’t you agree to whatever your QA guys want?” Sometimes I’ve found this to be a particular tricky one with highly opinionated engineers. Not specific to testing per say, but rather, why spend inordinate amounts of time talking around a topic, like testing, that is outside your team? Continuing to use your testing example … sure, your vocal engineers may think the QA folks are backwards and have their own opinions on how the QA guys should do their job. Try and focus the team’s energy on finding the most effective way to work with QA rather than kvetching about them.
I actually wrote a bit more on this opinion perspective on my blog here : http://bit.ly/1FVcmr
As one of my former bosses once told me “engineers always believe they know better how salespeople should work and salespeople always believe they know better how engineers should work.” The trick is to have organization which isn’t driven by only one group, no matter if they are developers, salespeople or db administrators, but to give authority for each group to deal with their chunk of responsibility.
However things become more difficult when you don’t think about relation between one independent team and another, but what you have is a boss or a leader and her team. She has authority over the rest of the team so she can easily enforce (or try to enforce at least) rules she like over engineers in the team.
The problem is it would hardly work, as in your example with administrators telling developers what should they do with coding. Actually even if the rules are reasonable and would help they wouldn’t likely work because of team’s resistance.
Paweł,
But don’t you think, you’re moving in a dangerous direction of making everything relative? There are things which are *just right*, not?
The other thing is, that for some practices one needs time, which initially is not so nice. Like pair-programming – it usually starts with some hiccups and slowly moves towards seamless and efective cooperation. Not that many teams will have courage and will to go though that period. Most (mainly bigger ones) would need a push and some creative pressure from someone (mgmt, team lead, etc.) to get to a next level of quality/effectiveness/colaboration.
Yes, I’m making most of it relative, because that’s how I perceive these things. But I’m not going to say there is no right thing. For me sure shots are continuous integration and continuous improvement. I haven’t seen an engineer who complained about having the former implemented in their organization. I haven’t seen anyone complaining about the latter, as long as anyone cared to actually improve anything.
So no, I don’t try to make it relative to the very last bit. And your organization is a proof that delegating all the decisions down to the people isn’t the only way to go. On the other hand you had comfort of setting rules beforehand, you didn’t have a crowd of developers already developing code.
What I don’t believe in is top-down approach to implement best practices. I agree there is important role for management here: to create environment which helps to sustain good practices, to evangelize, to encourage, maybe even to put some pressure. But this role shouldn’t be about making low-level engineering decisions. At least it shouldn’t be so most of the time.
When I was writing this post I had TDD in the back of my head. In your case it is one of technology fundamentals of the organization. In my case it would be artificial technique enforced on developers. I wanted to say that the difference is with developers, whether they believe in value of TDD, but I’ve realized it isn’t the only difference.
Another reason is, you were (and still are) an engineer in the first place, at the moment when you introduced TDD in your company. At the same time I’m barely a manger/leader but I don’t code anymore for years now. You were perceived more as a fellow engineer than as an employer, even though you used your bossy power to choose right candidates. My situation is different and maybe that’s why I’m way more reluctant when it comes to enforcing standards.
It seems for me like another advice like “there’s no silver bullet”, “do whatever works for you”, “I don’t know, experiment” :)
So… what works for me and my team?
Of course I don’t expect you to answer that. You don’t know me, my team or the working environment. But maybe there are some rules/guidance for manager/leader/team member just to start adapting best solutions for their work and then when team/project is evolving that helps not to fail.
I mean, you for sure have far more experience with team work than I do, so maybe I expected some advices how to adapt good practices :) They exist, right?
For sure I agree with the concept of letting specialists and people who will be affected to choose which tool/technology/practice they will use, not to force them. But what if they don’t agree on them, who should make decision? Is making decision forcing people to do so? Maybe they are lazy and figure out the way to work less for now on… Standards can be really helpful or become your enemy, but are they really so wrong at the beginning? Maybe leader/manager should focus on convincing people to agree or follow some rules (that should of course be discussed by all the affected people) rather than force them or even leaving them on their own (and by that I don’t mean self-organising).
It looks like I’m pretty consistent with my advices, isn’t it?
Besides “no silver bullet” and “do what works for you” I also happen to share what works for us, which is by the way intensively interlinked on the blog so I guess there is a need for such stuff.
But coming back to the point. Yes, I can point a couple of sure shots. I actually did in answer to Pawel’s comment: continuous integration and continuous improvement both qualify if you ask me, even though the latter could be hardly proclaimed an engineering practice.
You make a wrong assumption if you think I can deliver a better advice on choosing right engineering practices because I have a bit more experience. I don’t code actively for years already and users should be thankful for that. I’ve never did code review by myself. I pair programmed once for a few hours. Actually “pair programming” I should say since it didn’t look like you might expect. I wrote just a few unit tests in my whole career as a developer. So no, I don’t have more experience when it comes to best programming practices than any decent active developer out there, not to mention you.
Another question is what to do when people are just lazy and tend to ignore your effort to build a good development toolbox. Then we come back to manager/leader but not to find there a recipe for the best toolbox around but to do their darn job and try to ignite people to become at least good engineers. And if developers don’t make the transition they shouldn’t survive it either.
You got the point exactly stating that a manager should convince people – I see it exactly like that. But when a manger fails to convince developers it’s not worth the effort to just force them to.
Similar rules apply when folks can’t achieve consensus. A manager should facilitate discussion and work out some compromise among the team. It may look like “let’s try this and we’ll see how it works in a couple of moths.” Heck, it’s even better that way as it is the clue of continuous improvement.
By the way: I guess I should write another post on engineering practices, but this time sharing my opinions about specific ones. It will likely end up with flame war but I guess you want it anyway.