Lazy Driven Development

Lazy Driven Development (LDD) is a philosophy I have molded throughout my (short) career as a software developer.  How it works is somewhat self-explanatory, but before I explain what it means and why I still have a job, let me start by describing the commonly known practice of Test Driven Development (TDD), which encompasses many of the ideals I strive to manifest with LDD.

Test Driven Development

TDD is the development of software from a "let's hit this idea with a stick first" methodology.  

The basic workflow of TDD is thus:

• Determine a test for a path of logic that you intend to implement
• Create the necessary objects and methods for the test to run, typically as you write it
• See the test go red, attempt to make it green by filling in the blanks
• Determine more tests and repeat until the path of logic is 'complete'

laptop failing a battery test (let's make it pass!)

Reads like common sense, right?  What this methodology enforces is modular, testable code.  It provides developers a sensitivity for what really makes a stack testable, which allows other developers to better interpret and build upon that stack when future changes are made.  What this methodology does not encourage is the methodology itself.  The transition is awkward because the path of thinking is awkward, especially if you've been operating from an opposing mindset for the past decade.  I can see the pick-up being a minor setback for smaller or younger projects, but when you have a substantial legacy codebase and a host of set-in-their-way developers, you're going to find yourself fighting to keep this flow alive.  

test driven what?

Now I do understand that this method intends to save time, money, effort, pain, etc. in the long run, but that doesn't mean TDD (or BDD) is the most direct path to make those goals a reality.  You can achieve modular, testable code in many different ways and LDD is what I would like to introduce as my means toward that end.

Lazy Driven Development

So what is this, a metaphor for procrastination?  I gather that the term lazy is not what managers and leads first look for in an aspiring developer for their team, but let me explain what I mean by lazy.  The context here is that I only want to develop in a fashion that provides me the least amount of present work and follow-up work to achieve the goals I set forth.  Put another way, I want to get things done as efficiently and efficaciously as I can.  Of course this also means no cutting corners and mincing functionality, because such actions allocate technical debt and produce gaps in testing coverage that both in turn provide for a much more painful experience down the road.

done? done done.

Easy to type, but how does one actually do this?  Well let's think back to what TDD teaches us; model your logic in a way that facilitates testing and indicates its purpose clearly and concisely.  You don't need TDD to achieve that, just do it!  I see TDD as a means to a means toward proper coding.  You're forced into a modular, testable coding mindset because that is really the only sane path forward when working from that perspective.  It's almost difficult not to write clean code.  But once you have those ideals under your thumb, take off the training wheels and let loose.

one does not simply write obfuscated code either

Now I'm not saying that TDD is tedious and wrong, I believe it does serve an important purpose as an educational tool.  But once you have learned and mastered the bullet points I don't see much benefit toward straddling your focus to an outward-looking-in point of view.  Personally, I find that perspective more important when determining acceptance criteria for a story, but I generally don't find it conducive toward writing clean code quickly to complete that story. 

Conclusion

So that's Lazy Driven Development.  Sorry if you were expecting something more in-depth, but there really isn't a lot to it other than write code with a mindfulness for testing and maintainability.  I might provide an example of how I would approach a typical coding problem later on to demonstrate what this looks like.  Also keep in mind that Spring bean injection and mocking frameworks such as Mockito have made this path infinitely easier, so a lot of what I do is simply taking advantage of how easy it is now to isolate components toward a clear, intentional purpose.

So why is this here?

As I exercise parts of my brain I haven't used since College, let me explain a little bit about what I do first.  Yes, I realize that this is a tangent from the topic above, but bare with me here as I calibrate the wheels in my head. 

I am what one would term a software developer (or some such derivative).  My work is performed within a campus of the company named Thomson Reuters (TR).  I emphasize the word within, because the details of my organizational disposition is much more complicated than a simple employee-to-company relationship.  I like to think of my place in the org as working for a company that works for a company that works for consumers, with TR as the parent.  I am grossly over-simplifying here, but such granularity is not yet necessary (and perhaps it never will be).

radiate.aplacetoconnect.com

My current professional identity is that of Java, Spring, and REST.  Namely, I'm a back-end, web-dev guy, as my current project dictates.  The team I work within is however labeled a 'feature' team, which means somehow somewhere I will be working a full stack again.  A stack being from the interactive UI all the way down to the data pumping Hibernate DAO and RESTful Client layers.  Yes, I will again be able to immerse myself within the wild-west of ECMAScript.  So deep, I may never callback (ha).  

In all seriousness, I can feel the cobwebs glossing over my understanding of proper JavaScript design and development, and that was a fickle understanding to begin with.  Luckily, JavaScript has small potential for anti-patterns, right?  But my point here is not to rail on about the caveats of JavaScript, however immature and small-minded my presumptions are.  In all honesty I am excited to dive back in, because JavaScript is where the majority of web-development is and has been going.  Enough about those thoughts though, I will save my posturings for another day (perhaps for when I actually begin developing in JS again rather than pretending to do so). 

So where were we?  Ah yes, why this is here.  Well, I did not ask that question because I had an answer, and even if I did I do not believe it is my duty to answer it.  That responsibility is for you, the reader.  I have free reign to type whatever suits my mood, but you have free reign to navigate back to what actually interests you.  I hope that someday, maybe even today, one of my posts would fit that interest.  So I will leave it at that, and now that the wheels seem to be creaking back to life, I believe that this exercise has served my intended purpose.  If you got something out of it too, well, cool beans.