You Obtained management permission to test-drive!?
Inspired by Yareev's post
This is not an assault on Yareev directly, only inspired by his content.
This is not the first time I've heard about developers seeking permission from management to do their jobs and it's not just TDD, it is any aspect of your job. A Craftsperson doesn't ask for permission to do their job correctly or professionally. If you are in a situation where you need to ask for permission to your job correctly, take action now. You are doing the job you are doing ostensibly because you are an expert in your field and you know how to do the job correctly.
I'm not saying you cannot or should not inform your boss of what you are doing. More importantly you should share what your are doing with your team. If it makes you better, it might make them better too.
The need to ask or even inform management about the details of how you deliver outcomes is part of what I call Institutional Friction(tm). Software Craftsmanship is about doing the best possible job at delivering value to the business through software. Its not an art project, it's an engineering project that might look like art.
An engineer's purpose is to implement the simplest and most cost effective solution to a problem. Some sort of director person's job should be to point engineers at targets. The creamy filling is in some sense irrelvant to the business opportunity.
Related to the health and well-being of the engineer, and the sustainabiliy of the organization is one of the many aspects of how craftsmanship applies to the business proposition of developing software. Poorly crafted code can have negative impacts on both.
Engineers who have to maintain the poorly constucted, overly complicated, byzantine labrith of enterprise solutions grow weary, disenfranchised, and unproductive.
Businesses that have to maintain the same lose effectiveness in the market, suffer from increased operational cost, and limit their ability to pivot and chase new market demands.
Software Craftsmanship is about balancing between all of these forces. It is engineering proper. Therefore, as engineers we should not allow anyone to tell us how to create that balance by method, practice, or approach. We should accept input on where the right balance is.
Questions like What is the longevity of this platform or system? can shape how much effort we put into the pliability of its design. How integral is this applicaiton to daily operations? can effect how we consider durability and availability of the system. What are the consequence of data loss? can change the underlying economics of operations. These and many many more questions can lead engineers to draw proper conclusions about how to craft software.
The catch is two fold, first we need forthright answers to those questions. Secondly, we must insist upon being given the lattiude to choose the methods of execution to devliver a solution. We have become an integral part of business process and as thought workers and engineers; we need to become more engaged in meeting the goals of the organization.
6 comments:
Great post, Rich! On the other side of the coin, if you're a manager and you have to tell (demand, put in their objectives) your developers to use good engineering practices and help enforce that use, maybe you should look at your hiring practices.
Love it. Preach on big guy!
Nice post Rich.
Happy to be dirt in the oyster. As I got to splain you facewise, I had my own misgivings in writing that bullet point -- but at the time, for various reasons, I felt I needed permission for all sorts of things. Today I would not ask. Indeed, when later managers at the same workplace tried to bargain me out of test-driving, they got willing-to-discuss-it but no change in behavior. I got better, and I'm glad I left that bullet point as is because it brought on this post.
Great post.
If you ask for permission to do something you know is better....what was the point of having lived through the pain that grew in you the knowledge of that better way?
As a manager, I can and should tell the team what I/we/our customer wants and I will be basing those requests on my hard won knowledge and experience.
If I'm a smart manager, I've hired great people fully intending to trust them to do things right. You need the latitude to figure out how best to deliver it and if that includes TDD, then by damn, you should do that. Please make it visible to your teammates, hopefully through pairing and hopefully as a ratified part of a team definition of done.
Great post Rich.
Good one Rich. I think it's far more common to have to ask permission than it is to be empowered. A big part of that is human nature on the part of the developer (presumably, that's who you're talking to in this post).
Another big part of it is more pernicious, though - a need for control on the part of management.
That's much harder to overcome, IMHO.
Post a Comment