Strawberry Perl and Git on Windows, why doesn't Prove Work?

If you are having all kinds of Perl @INC problems and other strange behaviors with Perl on a Windows box and you have both Strawberry Perl and Git installed, check your class path order.

Turns out Git includes Perl 5.8.8 and it may be messing with your head. If you make sure Strawberry Perl is first in your path you will likely succeed more.

Thanks to Schmonz for helping me figure this out!

You Obtained management permission to test-drive!?

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.