# Jay Fields experiences in software development This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Starting a New Engagement as a Lead Consultant DevFeed: [Starting a New Engagement as a Lead Consultant]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2017-05-17T11:00:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [client](), [Software]() Tags: [advice](), [blog-post](), [consulting](), [delivery](), [enablement](), [lead](), [leadership](), [project](), [work]() ### AI overview A lead consultant reflects on starting new consulting engagements, arguing that there is no universal process. The article focuses on balancing client enablement with software delivery, identifying the client's actual needs, and improving people and processes without neglecting delivery. ### Source excerpt Someone recently asked me for information on starting new consulting engagements. A few years back I published Sean Doran and Scott Conley's thoughts on Being a Lead Consultant. Sean and Scott's list is great for any lead consultant, and the advice applies well for the lifetime of a project. I considered sending that list to the person looking for new engagement advice, but I'm not sure that list would be the best place to focus my attention at the beginning of a project. The beginning of a project is a special and dangerous time. You get a mix of (at least) optimism, concern, and freedom. There are a large number of ways the project can go, and as a lead consultant you'll play a major role determining it's outcome. The specific question I recently received was: did you have a process you followed when new engagements began. The remainder of this blog post contains my (slightly edited) response. I found being a lead at ThoughtWorks to be a nearly impossible balancing act. It's possible we didn't have a process because we weren't organized enough, but it's more likely that there's no general formula that works. What we ran into constantly was what we called the "enablement versus delivery" issue: If you're teaching client devs (enablement), you really don't have time to meet delivery deadlines; conversely if you're delivering software you rarely have time to teach. How to balance enablement versus delivery is something that varies based on the client's skillset and the ROI of the software being developed. What makes it worse is that the client often thinks they need one thing, but if the the company didn't have issues you (likely) wouldn't be there. Sometimes the issues are with the stakeholder and they'll tell you to focus on the wrong thing, and sometimes the stakeholder knows the deal but the other people you are forced to work with are the problem. Often it's a race to figure out what the client needs and get them to agree to fix it, before you've lost too much g ## Curious Customer DevFeed: [Curious Customer]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2016-06-28T15:24:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [bug](), [Software](), [unit tests](), [test](), [error reporting](), [coding]() Tags: [bugs](), [context](), [customers](), [developer](), [error-reporting](), [software](), [testing](), [tests](), [unit-tests]() ### AI overview A developer reflects on how bugs triggered by nonsensical user behavior created noise, context switching, and distrust in application data despite appearing minor. The article proposes having another developer use new features in staging as a "Curious Customer" to uncover issues that conventional tests may miss. ### Source excerpt I currently work on a pretty small team, 4 devs (including myself). We have no one dedicated strictly to QA. A few years ago we ran into a few unexpected issues with our software. I hesitate to call them bugs, because they only appeared when you did things that made little sense. We write internal-only software, thus we expect a minimum level of competency from our users. In addition, it's tempting justify ignoring problematic nonsensical behavior in the name of not having to write and maintain additional software. But, when I wasn't in denial, I was willing to admit that these were in fact bugs and they were costing us time. The problems caused by these bugs were small, e.g. a burst of worthless emails, a blip in data flowing to the application. The emails could be quickly deleted, and the application was eventually consistent. Thus I pretended as though these issues were of low importance, and that the pain was low for both myself and our customers. I imagine that sounds foolish; in retrospect, it was foolish. The cost of developer context switching is often very high, higher if it's done as an interrupt. Introducing noise into your error reporting devalues your error reporting. Users can't as easily differentiate between good data, a blip of bad data due to something they did, and actual bad data, thus they begin to distrust all of the data. The cost of these bugs created by nonsensical behavior is high, much higher than the cost of writing and maintaining the software that eliminated these bugs. Once we eliminated these bugs, I spent notably more time happily focused on writing software. For me, delivering features is satisfying; conversely, tracking down issues stemming from nonsensical behavior always feels like a painfully inefficient task. I became very intent on avoiding that inefficiency in the future. The team brainstormed on how to address this behavior, and honestly we came up with very little. We already write unit tests, load tests, and integration te ## Maintainability and Expect Literals DevFeed: [Maintainability and Expect Literals]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2016-06-16T11:21:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Maintainability](), [unit test](), [test](), [Code](), [function](), [formatting]() Tags: [advice](), [alternatives](), [code](), [formatting](), [function](), [literals](), [maintainability](), [readability](), [test](), [testing](), [tests](), [unit-test](), [unit-testing](), [wewut](), [xunit]() ### AI overview The author argues that literal expected values in unit tests improve readability and keep failures focused, while helper functions can broaden the scope of maintenance and couple tests. For changing or inconsistent strings, the article suggests duplication with bulk edits or testing variable-dependent behavior separately from formatting. ### Source excerpt Recently, Stephen Schaub asked the following on the wewut group: Several of the unit test examples in the book verify the construction of both HTML and plain text strings. Jay recommends using literal strings in the assertions. However, this strikes me as not a particularly maintainable approach. If the requirements regarding the formatting of these strings changes (a very likely scenario), every single test that verifies one of these strings using a literal must be updated. Combined with the advice that each test should check only one thing, this leads to a large number of extremely brittle tests. Am I missing something here? I can appreciate the reasons Jay recommends using literals in the tests. However, it seems that we pay a high maintainability price in exchange for the improved readability. I responded to Stephen; however, I've seen similar questions asked a few times. Below are my extended thoughts regarding literals as expected values. In general, given the option of having many similar strings (or any literal) vs a helper function, I would always prefer the literal. When a test is failing I only care about that single failing test. If I have to look at the helper function I no longer have the luxury of staying focused on the single test; now I need to consider what the helper function is giving me and what it's giving all other callers. Suddenly the scope of my work has shifted from one test to all of the tests coupled by this helper function. If this helper function wasn't written by me, this expansion in scope wasn't even my decision, it was forced upon me by the helper function creator. In the best case the helper function could return a single, constant string. The scope expansion becomes even worse when the helper function contains code branches. As for alternatives, my solution would depend on the problem. If the strings were fairly consistent, I would likely simply duplicate everything knowing that any formatting changes can likely be addressed usin ## Drop Books DevFeed: [Drop Books]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2015-06-25T13:47:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Refactoring](), [legacy](), [Architecture & Design](), [Enterprise Architecture]() Tags: [books](), [enterprise-architecture](), [legacy-code](), [patterns](), [refactoring](), [technical]() ### AI overview The author describes "Drop Books," technical books repeatedly purchased and given to friends and colleagues to spread useful programming ideas. The recommended books include Refactoring, Working Effectively with Legacy Code, Passionate Programmer, and Patterns of Enterprise Architecture. ### Source excerpt The vast majority of books I purchase are for my own enjoyment, but not all of them. There are a few books that I buy over and over, and drop on the desks of friends and colleagues. These books, all technical, are books that I think most programmers will benefit from reading. I call these books "Drop Books"; I drop them and never expect them to be returned. My main motivation for dropping books is to spread what I think are great ideas. Specifically, I'm always happy to spread the ideas found in the following books: Refactoring Working Effectively with Legacy Code Passionate Programmer Patterns of Enterprise Architecture I know a few of my friends buy Drop Books as well. Spreading solid ideas and supporting authors seems like a win/win to me; hopefully more and more people will begin to do the same. © Jay Fields - www.jayfields.com ## Unit Testing Points of View: A Collaborative Book on Unit-Testing Styles and Trade-offs DevFeed: [Unit Testing Points of View: A Collaborative Book on Unit-Testing Styles and Trade-offs]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2015-04-06T17:20:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Testing](), [Unit testing](), [Test-driven development](), [Software Engineering]() Tags: [book](), [books](), [tdd](), [testing](), [unit-testing](), [unit-tests]() ### AI overview The article announces a collaborative book by Michael Feathers, Brian Marick, and the author about unit-testing styles. It aims to document the reasoning and trade-offs behind different approaches by evolving tests for a shared domain model. ### Source excerpt Michael Feathers, Brian Marick, and I are collaborating to create a new book: Unit Testing Points of View ... probably. Origin In 2014 Martin Fowler provided Technical Review for Working Effectively with Unit Tests. As part of his feedback he said something along the lines of: I'm glad you wrote this book, and I'll likely write a bliki entry noting what I agree with and detailing what I would do differently. I'm still looking forward to that entry, and I think the idea is worth extending beyond Martin. Unit testing is now mainstream, has tons of entry level books, and has a great reference book. The result is a widely accepted idea that you can quickly and easily adopt; unfortunately, I've found little in the way of documenting pattern trade-offs. I believe that combination leads to a lot of waste. To help avoid some of that waste, I'd like to see more written about why you may want to choose one Unit Testing style over another. That was the inspiration and my goal for Working Effectively with Unit Tests. Growing Object-Oriented Software is another great example of a book that documents both the hows and whys of unit testing. After that, if you're looking for tradeoff guidance... good luck. Is this a problem? I think so. Without discussion of tradeoffs, experience reports, and concrete direction you end up with hours wasted on bad tests and proclamations of TDD's death. The report of TDD's death was an exaggeration, and the largest clue was the implication that TDD and Unit Testing were synonymous. To this day, Unit Testing is still largely misunderstood. What could be Working Effectively with Unit Tests starts with one set of opinionated Unit Tests and evolves to the types of Unit Tests that I find more productive. There's no reason this evolution couldn't be extended by other authors. This is the vision we have for Unit Testing Points of View. Michael, Brian, and I began by selecting a common domain model. The first few chapters will detail the hows and whys of ho ## My Answers for Microservices Awkward Questions DevFeed: [My Answers for Microservices Awkward Questions]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2015-03-15T21:48:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Microservices](), [Development](), [Software Engineering]() Tags: [coupling](), [experience-report](), [independent](), [microservices](), [software-development]() ### AI overview An experience report about developing several small, independently deployable codebases that collaborate to provide a single user experience. The author explains that reducing accidental coupling, rather than adopting microservices as a goal, motivated the approach, while noting that the choice involves tradeoffs and is not universally applicable. ### Source excerpt Earlier this year, Ade published Awkward questions for those boarding the microservices bandwagon. I think the list is pretty solid, and (with a small push from Ade) I decided to write concise details on my experience. I think it's reasonable to start with a little context building. When I started working on the application I'm primarily responsible for microservices were very much fringe. Fred George was already giving (great) presentations on the topic, but the idea had gained neither momentum nor hype. I never set out to write "microsevices"; I set out to write a few small projects (codebases) that collaborated to provide a (single) solid user experience. I pushed to move the team to small codebases after becoming frustrated with a monolith I was a part of building and a monolith I ended up inheriting. I have no idea if several small codebases are the right choice for the majority, but I find they help me write more maintainable software. Practically everything is a tradeoff in software development; when people ask me what the best aspect of a small services approach is, I always respond: I find accidental coupling to be the largest productivity drain on projects with monolithic codebases. Independent codebases reduce what can be reasonably accidentally coupled. As I said, I never set out to create microservices; I set out to reduce accidental coupling. 3 years later, it seems I have around 3 years of experience working with Microservies (according to the wikipedia definition). I have nothing to do with microservices advocacy, and you shouldn't see this entry as confirmation or condemnation of a microservices approach. The entry is an experience report, nothing more, nothing less. On to Ade's questions (in bold). Why isn't this a library?: It is. Each of our services compile to a jar that can be run independently, but could just as easily be used as a library. What heuristics do you use to decide when to build (or extract) a service versus building (or extracting ## Experience Report: Weak Code Ownership DevFeed: [Experience Report: Weak Code Ownership]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2015-02-23T15:00:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Code](), [Software](), [optimize]() Tags: [code](), [collective](), [developers](), [experience-report](), [opinions](), [optimize](), [team]() ### AI overview The author reflects on moving from Collective Code Ownership to advocating Weak Code Ownership after experiencing disagreement and reduced productivity on a team of senior developers. The article argues that talented developers often work in incompatible ways, making it difficult to optimize a shared process for everyone. ### Source excerpt In 2006 Martin Fowler wrote about Code Ownership. It's a quick read, I'd recommend checking it out if you've never seen it. At the time I was working at ThoughtWorks; I remember thinking "Clearly Strong makes no sense and I have no idea what scenario would make Weak reasonable". 8 years later, I find myself advocating for Weak Code Ownership within my team. Collective Code Ownership (CCO) served me well between 2005 and 2009. Given the make-up of the teams that I was a part of I found it to be the most effective way to deliver software. Around 2009 I joined a team that eventually grew to around 9 people, all very senior developers. The team practiced Collective Code Ownership. Everyone on the team was very talented, but that didn't translate to constant agreement. In fact, we disagreed far more often than I thought we should. That experience drove me to write about the importance of Compatible Opinions. I still believe in the importance of compatible opinions, but I now wonder if the team wouldn't have been more effective (despite incompatible opinions) if we had adopted Weak Code Ownership. The 2009 project heavily shaped my approach to developing software. I suspect I'm not the only one who (at one time) believed: if we get a team full of massively talented people we can do anything. It turns out, it's not nearly that easy. Too many cooks in the kitchen is the obvious concern, and it does come up. However, the much larger problem is that talented people work in vastly different ways. Some meticulously refactor in small steps, others make wide reaching and large changes. Some prefer one language to rule them all, others are comfortable switching between 12-15 different languages in the same day. Monolithic vs separated codebases. Inherited vs duplicated config. It goes on and on. You try to optimize for everyone, to ensure everyone is maximally effective. Pretty quickly you run into this situation- If you optimize everything, you will always be unhappy. --Donald Kn ## Preview Arbitrary HTML DevFeed: [Preview Arbitrary HTML]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2015-01-08T15:23:00Z Content type: tutorial Language: en Sources: [Jay Fields]() Topics: [HTML](), [gist](), [GitHub](), [Markdown]() Tags: [gist](), [github](), [html](), [markdown]() ### AI overview A short tutorial explains how to preview arbitrary HTML by changing a GitHub Gist file extension to .md. GitHub renders Markdown Gists with inline HTML, making this useful for sharing short-lived rendered HTML. ### Source excerpt I'm a big fan of https://gist.github.com/ for sharing code. It's fantastic for quickly putting something online to talk over with someone else. I've often found myself wishing for something that allowed me to share rendered HTML in the same way. For example, a gist of the HTML for this blog entry can be seen here: https://gist.github.com/jaycfields/82e2cc0a588bd83a91f4. If I want someone to give me feedback on the rendered output, that gist isn't very helpful. It turns out, it's really easy to see that HTML rendered: switch the file extension to md. Here's the same gist with a md extension: https://gist.github.com/jaycfields/e383b12b6ff9bd49c40a This all works due to the way Github renders markdown gists, and markdown supporting inline HTML. I wouldn't use this trick to create any data you'd like to have online in the long term, but it's great for sharing short lived HTML. © Jay Fields - www.jayfields.com ## Making Remote Work: Tools DevFeed: [Making Remote Work: Tools]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2015-01-06T13:27:00Z Content type: article Language: en Sources: [Jay Fields]() Topics: [GitHub](), [Pull Request](), [Wiki](), [Cisco](), [pair\_programming]() Tags: [chat](), [cisco](), [github](), [process](), [pull-request](), [remote](), [remote-work](), [tools]() ### AI overview This article presents a snapshot of the communication and collaboration tools used by a remote team. It describes GitHub pull requests and compare view for asynchronous code discussion, Hipchat rooms for separating communication by purpose, Cisco Jabber for video calls and desktop sharing, and a Confluence wiki for organizing the team backlog. The author explicitly states that the list is not a recommended set of tools. ### Source excerpt I recently wrote about my experiences working on a remote team. Within that blog entry you can find a more verbose version of the following text: Communication is what I consider to be the hardest part of remote work. I haven't found an easy, general solution. A few teammates prefer video chat, others despise it. A few teammates like the wiki as a backlog, a few haven't ever edited the wiki. Some prefer strict usage of email/chat/phone for async-unimportant/async-important/sync-urgent, others tend to use one of those 3 for all communication. As you can tell, we have several different communication tools. When writing, I generally prefer to include concrete examples. This blog entry will list each tool referenced above. However, I cannot emphasize enough that: this list is a snapshot of what we're using, not a recommended set of tools. app: Github usage: We use many of the features of Github; however, the two features that help facilitate remote work are (a) pull requests with inline comments and (b) compare. A pull request with inline comments has (thus far) been the most productive way to asynchronously discuss specific pieces of code. Almost all non-trivial commits will eventually end up in a pull request that's reviewed by at least one other team member. We've found compare view to be the best solution for distilling changes for a teammate with limited context. app: Hipchat usage: We have 3 hipchat rooms: work, social, support. It should be pretty obvious what we use each room for. The primary driver for splitting the 3 is for keeping noise down. Most team members look at chat history for work and support, reading anything that happened between now and the last time they were logged in. Social tends to be more verbose, often off-topic, and never required reading for keeping up with what the team is up to. app: Cisco Jabber usage: Within the team, we primarily use Cisco Jabber for video calls; however Cisco Jabber is also a great way for people within DRW offices ## Making Remote Work DevFeed: [Making Remote Work]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2014-12-28T19:32:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [experience report]() Tags: [experience](), [process](), [productivity](), [remote-work](), [report](), [team]() ### AI overview An experience report about a software team's transition from co-located work to a fully distributed arrangement across several cities. The author reports no decline in productivity or camaraderie and improved happiness from traveling less, while cautioning that the account is based on personal observations rather than general best practices. ### Source excerpt Over 18 months ago I wrote Year Five, an experience report I never imagined I would write. I closed the blog entry by saying I look forward to writing about Year Six. A year and a half later, I'm still having a hard time deciding what (if anything) I should write. My writers block isn't the result the Remote Work experiment failing. Quite the opposite, the success of the Remote Work experiment has helped shape a team I'm very proud to be a part of, and yet I find myself unable to declare victory. "How can you work effectively with remote teammates" has become the most common question I hear when meeting up with old colleagues for coffee. Clearly people are interested in the topic. At the same time, I prefer not to write about half-baked ideas (these days), thus my apprehension in documenting my approach. This entry is an experience report, nothing more, nothing less. I'd be very skeptical of anyone providing recipes or best practices around remote work. Those working remotely today are breaking traditional workplace rules. Some are succeeding, most are failing, and I don't know of anyone with solid general advice. What follows are merely my observations. My team became remote on accident. My boss and I were a 2 person co-located team in NYC, he quit, they gave me his job, and my best option to fill my previous role lived in Chicago. David Chelimsky was willing to be in NYC 2 weeks out of the month, and I was willing to be in Chicago 1 week out of the month. It was effectively co-location, and our team ran that way for a couple months. Sometime in month three I started to feel like having David in NYC 2 weeks a month was unnecessary, and (surprisingly to me) he'd independently come to the same conclusion. From that point forward we alternated on traveling 1 week a month - thus we worked remotely for 3 weeks out of 4. We saw no drop off in our productivity or camaraderie, and traveling less definitely improved our overall happiness. I'm not sure how it would have work ## Working Effectively with Unit Tests Official Launch DevFeed: [Working Effectively with Unit Tests Official Launch]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2014-12-17T06:00:00Z Content type: release Language: en Sources: [Jay Fields]() Topics: [Unit testing](), [Testing]() Tags: [acceptance-tests](), [functional-testing](), [java](), [one-assertion-per-test](), [pdf](), [release](), [split-test-suite](), [tdd](), [test](), [test-names](), [testing](), [testing-immaturity](), [testing-private-methods](), [testing-refactorings](), [unit-testing]() ### AI overview Jay Fields announces the official release of Working Effectively with Unit Tests. The book is available in PDF, EPUB, MOBI, softcover, and Kindle editions, with a web or PDF sample available. ### Source excerpt Today marks the official release release of Working Effectively with Unit Tests. The book is available in various formats: DRM free pdf, epub, & mobi (Kindle) at http://leanpub.com/wewut Softcover at http://amzn.com/1503242706 Kindle edition at http://amzn.com/B00QS2HXUO I'm very happy with the final version. Michael Feathers wrote a great foreword. I incorporated feedback from dozens of people - some that have been friends for years, and some that I'd never previously met. I can't say enough great things about http://leanpub.com, and I highly recommend it for getting an idea out there and making it easy to get fast feedback. As far as the softcover edition, I had offers from a few major publishers, but in the end none of them would allow me to continue to sell on leanpub at the same time. I strongly considered caving to the demands of the major publishers, but ultimately the ability to create a high quality softcover and make it available on Amazon was too tempting to pass up. The feedback has been almost universally positive - the reviews are quite solid on goodreads (http://review.wewut.com). I believe the book provides specific, concise direction for effective Unit Testing, and I hope it helps increase the quality of the unit tests found in the wild. If you'd like to try before you buy, there's a sample available in pdf format or on the web. © Jay Fields - www.jayfields.com ## Solitary Unit Test DevFeed: [Solitary Unit Test]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2014-07-16T19:55:00Z Content type: tutorial Language: en Sources: [Jay Fields]() Topics: [Testing](), [Unit testing](), [Mocking](), [Refactoring]() Tags: [advice](), [refactoring](), [testing](), [tests](), [unit-test](), [unit-testing](), [unit-tests]() ### AI overview The article defines solitary unit testing as isolating the class or namespace under test by stubbing collaborations with other classes and namespaces. It recommends avoiding external boundaries such as databases, networks, and filesystems, while noting that the approach depends on suitable stubbing and refactoring tools. ### Source excerpt Originally found in Working Effectively with Unit Tests It's common to unit test at the class level. The Foo class will have an associated FooTests class. Solitary Unit Tests follow two additional constraints: Never cross boundaries The Class Under Test should be the only concrete class found in a test. Never cross boundaries is a fairly simple, yet controversial piece of advice. In 2004, Bill Caputo wrote about this advice, and defined a boundary as: "...a database, a queue, another system...". The advice is simple: accessing a database, network, or file system significantly increases the the time it takes to run a test. When the aggregate execution time impacts a developer's decision to run the test suite, the effectiveness of the entire team is at risk. A test suite that isn't run regularly is likely to have negative-ROI. In the same entry, Bill also defines a boundary as: "... or even an ordinary class if that class is 'outside' the area your [sic] trying to work with or are responsible for". Bill's recommendation is a good one, but I find it too vague. Bill's statement fails to give concrete advice on where to draw the line. My second constraint is a concrete (and admittedly restrictive) version of Bill's recommendation. The concept of constraining a unit test such that 'the Class Under Test should be the only concrete class found in a test' sounds extreme, but it's actually not that drastic if you assume a few things. You're using a framework that allows you to easily stub most concrete classes This constraint does not apply to any primitive or class that has a literal (e.g. int, Integer, String, etc) You're using some type of automated refactoring tool. There are pros and cons to this approach, both of which are examined in Working Effectively with Unit Tests. Solitary Unit Test can be defined as: Solitary Unit Testing is an activity by which methods of a class or functions of a namespace are tested to determine if they are fit for use. The tests used to dete ## Working Effectively with Unit Tests Rough Draft Complete DevFeed: [Working Effectively with Unit Tests Rough Draft Complete]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2014-07-01T00:48:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [unit tests](), [test](), [Test-driven development](), [Git](), [Ruby]() Tags: [books](), [git](), [test](), [tests](), [unit-tests](), [wewut](), [writing]() ### AI overview The author reflects on completing the rough draft of Working Effectively with Unit Tests, publishing it early on Leanpub, and using reader feedback to improve the book. The article also describes a script and output-file comparisons used to verify that the book's passing and failing examples continue to behave as intended. ### Source excerpt I finally put the finishing touches on the rough draft of Working Effectively with Unit Tests. It's been an interesting journey thus far, and I'm hoping the attention to detail I've put into the rough draft will translate into an enjoyable read. What I did poorly: I'd written the book's sample before I ever put it on leanpub. Before a book is published you can collect contact and price information from those who are interested. However, once you publish and begin selling, you no longer have the ability to collect the previously mentioned information. I published and began selling my book immediately - and forfeited my chance to collect that information. What I did well: I published early and often. I can't say enough nice things about leanpub. I've gotten tons of feedback on example style, writing style, typos, and content. One reader's suggestion to switch to Kevlin Henney's Java formatting style made my book enjoyable to read on a Kindle. I had twitter followers apologizing for "being pedantic and pointing out typos", and I couldn't have been happier to get the feedback. Each typo I fix makes the book more enjoyable for everyone. If you're going to write a book, get it on leanpub asap and start interacting with your audience. What I learned from Refactoring: Ruby Edition (RRE): RRE contains errors, far too many errors. I vowed to find a better way this time around, and I'm very happy with the results. Every example test in the book can be run, and uses classes also shown in the book. However, writing about tests is a bit tricky: sometimes "failure" is the outcome you're looking to document. Therefore, I couldn't simply write tests for everything. Instead I piped the output to files and used them as example output in the book, but also as verification that what failed once continued to fail in the future (and vice versa). WEwUT has a script that runs every test from the book and overwrites the output files. If the output files are unchanged, I know all the passing ## Working Effectively with Unit Tests DevFeed: [Working Effectively with Unit Tests]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2014-05-21T11:29:00Z Content type: article Language: en Sources: [Jay Fields]() Topics: [Unit testing](), [Testing](), [Refactoring](), [maintenance]() Tags: [functional-testing](), [java](), [maintenance](), [refactoring](), [testing](), [unit-testing](), [unit-tests]() ### AI overview The author introduces a book about making unit tests more productive and maintainable. It presents lessons from years of testing experience and advocates fine-grained, readable tests with limited scope, explicit collaborators, single-responsibility focus, and resistance to cascading failures. ### Source excerpt Unit Testing has moved from fringe to mainstream, which is a great thing. Unfortunately, as a side effect developers are creating mountains of unmaintainable tests. I've been fighting the maintenance battle pretty aggressively for years, and I've decided to write a book that captures what I believe is the most effective way to test. From the Preface Over a dozen years ago I read Refactoring for the first time; it immediately became my bible. While Refactoring isn't about testing, it explicitly states: If you want to refactor, the essential precondition is having solid tests. At that time, if Refactoring deemed it necessary, I unquestionably complied. That was the beginning of my quest to create productive unit tests. Throughout the 12+ years that followed reading Refactoring I made many mistakes, learned countless lessons, and developed a set of guidelines that I believe make unit testing a productive use of programmer time. This book provides a single place to examine those mistakes, pass on the lessons learned, and provide direction for those that want to test in a way that I've found to be the most productive. The book does touch on some theory and definition, but the main purpose is to show you how to take tests that are causing you pain and turn them into tests that you're happy to work with. For example, the book demonstrates how to go from... looping test with many (built elsewhere) collaborators .. to individual tests that expect literals, limit scope, explicitly define collaborators, and focus on readability .. to fine-grained tests that focus on testing a single responsibility, are resistant to cascading failures, and provide no friction for those practicing ruthless Refactoring. As of right now, you can read the first 2 chapters for free at https://leanpub.com/wewut/read I'm currently ~25% done with the book, and it's available now for $14.99. My plan is to raise the price to $19.99 when I'm 50% done, and $24.99 when I'm 75% done. Leanpub offers my book w ## Weighing in on Long Live Testing DevFeed: [Weighing in on Long Live Testing]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2014-05-19T16:52:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Testing](), [Test-driven development](), [unit tests](), [Refactoring](), [pair\_programming]() Tags: [behavior](), [code-coverage](), [java](), [pair-programming](), [refactoring](), [tdd](), [testing](), [unit-testing](), [unit-tests]() ### AI overview The author argues that test-driven development and testing practices should be chosen based on their purpose and context rather than followed dogmatically. Drawing on experience with a simple internal application, the article emphasizes asking why a test is being written and identifies goals such as validation, regression prevention, coverage, legacy-code refactoring, and documenting system behavior. ### Source excerpt DHH recently wrote a provocative piece that gave some views into how he does and doesn't test these days. While I don't think I agree with him completely, I applaud his willingness to speak out against TDD dogma. I've written publicly about not buying the pair-programming dogma, but I hadn't previously been brave enough to admit that I no longer TDD the vast majority of the time. The truth is, I haven't been dogmatic about TDD in quite some time. Over 6 years ago I was on a ThoughtWorks project where I couldn't think of a single good reason to TDD the code I was working on. To be honest, there weren't really any reasons that motivated me to write tests at all. We were working on a fairly simple, internal application. They wanted software as fast as they could possibly get it, and didn't care if it crashed fairly often. We kept everything simple, manually tested new features through the UI, and kept our customer's very happy. There were plenty of reasons that we could have written tests. Reasons that I expect people will want to yell at me right now. To me, that's actually the interesting, and missing part, of the latest debate on TDD. I don't see people asking: Why are we writing this test? Is TDD good or bad? That depends; TDD is just a tool, and often the individual is the determining factor when it comes to how effective a tool is. If we start asking "Why?", it's possible to see how TDD could be good for some people, and bad for DHH. I've been quietly writing a book on Working Effectively with Unit Tests, and I'll have to admit that it was really, really hard not to jump into the conversation with some of the content I've recently written. Specifically, I think this paragraph from the Preface could go a long way to helping people understand an opposing argument. Why Test? The answer was easy for me: Refactoring told me to. Unfortunately, doing something strictly because someone or something told you to is possibly the worst approach you could take. The more time ## REPL Driven Development DevFeed: [REPL Driven Development]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2014-01-27T17:53:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Development](), [Code](), [Software](), [Test-driven development]() Tags: [application](), [c-sharp](), [clojure](), [code](), [development](), [emacs](), [evaluation](), [expression](), [java](), [junit](), [nunit](), [productivity](), [repl](), [ruby](), [running](), [software](), [verification](), [writing]() ### AI overview The article explains REPL Driven Development (RDD), a workflow in which developers craft s-expressions, evaluate them immediately in a REPL, inspect the results or apply changes to a running application, and repeat until the problem is solved. The author argues that avoiding application restarts, separate verification tools, and leaving the source enables faster feedback while writing production code. ### Source excerpt When I describe my current workflow I use the TLA RDD, which is short for REPL Driven Development. I've been using REPL Driven Development for all of my production work for awhile now, and I find it to be the most effective workflow I've ever used. RDD differs greatly from any workflow I've used in the past, and (despite my belief that it's superior) I've often had trouble concisely describing what makes the workflow so productive. This entry is an attempt to describe what I consider RDD to be, and to demonstrate why I find it the most effective way to work. RDD Cycle First, I'd like to address the TLA RDD. I use the term RDD because I'm relying on the REPL to drive my development. More specifically, when I'm developing, I create an s-expression that I believe will solve my problem at hand. Once I'm satisfied with my s-expression, I send that s-expression to the REPL for immediate evaluation. The result of sending an s-expression can either be a value that I manually inspect, or it can be a change to a running application. Either way, I'll look at the result, determine if the problem is solved, and repeat the process of crafting an s-expression, sending it to the REPL, and evaluating the result. If that isn't clear, hopefully the video below demonstrates what I'm talking about. If you're unfamiliar with RDD, the previous video might leave you wondering: What's so impressive about RDD? To answer that question, I think it's worth making explicit what the video is: an example of a running application that needs to change, a change taking place, and verification that the application runs as desired. The video demonstrates change and verification; what makes RDD so effective to me is what's missing: (a) restarting the application, (b) running something other than the application to verify behavior, and (c) moving out of the source to execute arbitrary code. Eliminating those 3 steps allows me to focus on what's important, writing and running code that will be executed in ## Coding: Increase Your Reading and Writing Speed DevFeed: [Coding: Increase Your Reading and Writing Speed]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-06-11T17:31:00Z Content type: tutorial Language: en Sources: [Jay Fields]() Topics: [coding](), [Snippet](), [Emacs](), [ide](), [optimize](), [Clojure]() Tags: [clojure](), [coding](), [emacs](), [ide](), [optimize](), [productivity](), [snippet]() ### AI overview The article explains how to use code-frequency analysis to choose a small number of editor shortcuts, snippets, and custom font locks. It illustrates the approach with Clojure code, Emacs, and IntelliJ examples. ### Source excerpt A teammate of mine recently expressed a desire for a shortcut for something we type often. I started looking into our shortcut options and came to a common determination: We can do this, but the number of 2 key shortcuts available to us is finite, so we better use them wisely. I wrote the following unix to give me a rough idea of what we type frequently. find . -name "*.clj" | xargs cat | tr -s '[:space:]:#()[]{}\"' '\n' | sort | uniq -c | sort -nnote: If you're not writing clojure you'll want to look for something other than .clj files, and you might also want to tweak what you replace with a new line. The above unix gave me an ordered list of the most typed 'words' across all of my codebases. At this point I had some science for setting up some shortcuts. Writing You'll want to look into whatever editor/ide you use and see if you can find key shortcuts and snippet expansion. My editor is emacs; I assigned some key-chords and some yasnippets. If you're not using emacs you should have something similar in whatever you are using. While I wanted to define some shortcuts, I also didn't want to create so many that I was constantly wasting time looking up what I'd created. Based on that desire I created: 2 shortcuts (key-chords) for two of the most duplicated words. The shortcuts are concise by design, but that makes them a bit harder to remember. You can probably get started with more than 2, but I didn't see much harm in starting there. a dozen snippets for the next most used words. These snippets are descriptive enough to easily remember, thus I felt comfortable defining several of them. e.g. pps expands to (println (pr-str )). Having shortcuts and snippets will obviously make me more productive, and the unix helped me figure out which words were the most important to optimize for. Reading Most editors/ides also give you a summary view for common code patterns. For example, IntelliJ displays lambdas when the actual code is actually an anonymous class. Emacs gives you ## Clojure: Combining Calls To Doseq And Let DevFeed: [Clojure: Combining Calls To Doseq And Let]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-05-16T12:00:00Z Content type: tutorial Language: en Sources: [Jay Fields]() Topics: [Clojure](), [function](), [iteration](), [Code]() Tags: [clojure](), [clojure-functions](), [code](), [function](), [iteration](), [modifiers]() ### AI overview This Clojure tutorial explains that doseq supports the :let, :when, and :while modifiers also available in the for macro. It compares multiple doseqs with multiple bindings, noting that binding choices can change how often functions are evaluated and that :let can control evaluation frequency. ### Source excerpt I've you've ever looked at the docs for clojure's for macro, then you probably know about the :let, :when, and :while modifiers. What you may not know is that those same modifiers are available in doseq. I was recently working with some code that had the following form. Upon seeing this code, John Hume asked if I preferred it to a single doseq with multiple bindings. He sent over an example that looked similar to the following example. That was actually the first time that I'd seen multiple bindings in a doseq, and my immediate reaction was that I preferred the explicit simplicity of having multiple doseqs. However, I always have a preference for concise code, and I forced myself to starting using multiple bindings instead of multiple doseqs - and, unsurprisingly, I now prefer multiple bindings to multiple doseqs. You might have noticed that the second version of the code slightly changes what's actually being done. In the original version the 'name' function is called once per 'id', and in the second version the 'name' function is called once per 'sub-id'. Calling name significantly more often isn't likely to have much impact on your program; however, if you were calling a more expensive function this change could have a negative impact. Luckily, (as I previously mentioned) doseq also provides support for :let. The second example can be evolved to the following code - which also demonstrates that the let is only evaluated once per iteration. That's really the final version of the original code, but you can alter it slightly for experimentation purposes if you'd like. Let's assume we have another function we're calling in an additional let and it's expensive, it would be nice if that only occurred when an iteration was going to happen. It turns out, that's exactly what happens. Whether you prefer multiple bindings or multiple doseqs, it's probably a good idea to get comfortable reading both. © Jay Fields - www.jayfields.com ## Emacs Lisp: Font Lock for Clojure's Partial DevFeed: [Emacs Lisp: Font Lock for Clojure's Partial]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-05-15T12:00:00Z Content type: tutorial Language: en Sources: [Jay Fields]() Topics: [Clojure](), [Emacs](), [Lisp](), [function](), [Code]() Tags: [clojure](), [code](), [emacs](), [emacs-lisp](), [emacs-live](), [function](), [lisp](), [standard-library]() ### AI overview The article explains how to use Clojure mode font locking in Emacs to display the standard Clojure partial function in a single character space while retaining the familiar partial function in the code. ### Source excerpt I love using partial, but I dislike the length of the function name. There's a simple solution, define another function with a shorter name that simply calls (or is) partial. This is exactly what I did in the jry library. I liked the use of % due to partial feeling similar to creating a function using #(), and % having a special meaning inside #(). I thought they tied well together. Unfortunately, there's an obvious problem, things would be very broken if you tried to use the '%' function in an anonymous function defined with #(). Somewhere along the way this issue caused me to stop using jry/%. Using partial is great: it's part of the standard lib, and I don't need to explain it to anyone who joins my team or any future maintainers of the code I write. Still, I want something shorter, and I've always had a background thread looking for another shorter-than-partial solution. While recently contributing to emacs-live I found the solution I was looking for: clojure-mode font lock. The following code can now be found in my emacs configuration. This solution feels like the best of both worlds. My code still uses the function from the standard library, my colleagues still see a function they already know, and 'partial' only takes up one character space in my buffer. The image below is what you'll see if you put the above emacs-lisp in your config. © Jay Fields - www.jayfields.com ## Clojure: Testing The Creation Of A Partial Function DevFeed: [Clojure: Testing The Creation Of A Partial Function]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-05-14T12:00:00Z Content type: article Language: en Sources: [Jay Fields]() Topics: [Clojure](), [Testing](), [Refactoring](), [function]() Tags: [clojure](), [clojure-functions](), [function](), [refactoring](), [test](), [testing]() ### AI overview This Clojure article examines testing a refactoring that replaces stored data with a partially applied function. It explains how to verify the function and arguments using redefinition, while comparing state-based and implementation-focused tests and their maintenance trade-offs. ### Source excerpt I recently refactored some code that takes longs from two different sources to compute one value. The code originally stored the longs and called a function when all of the data arrived. The refactored version partials the data while it's incomplete and executes the partial'd function when all of the data is available. Below is a contrived example of what I'm taking about. Let's pretend we need a function that will allow us to check whether or not another drink would make us legally drunk in New York City. The code below stores the current bac and uses the value when legally-drunk? is called. The following (passing) tests demonstrate that everything works as expected. This code works without issue, but can also be refactored to store a partial'd function instead of the bac value. Why you would want to do such a thing is outside of the scope of this post, so we'll just assume this is a good refactoring. The code below no longer stores the bac value, and instead stores the pure-legally-drunk? function partial'd with the bac value. Two of the three of the tests don't change; however, the test that was verifying the state is now broken. note: The test output has been trimmed and reformatted to avoid horizontal scrolling. In the output you can see that the test is failing as you'd expect, due to the change in what we're storing. What's broken is obvious, but there's not an obvious solution. Assuming you still want this state based test, how do you verify that you've partial'd the right function with the right value? The solution is simple, but a bit tricky. As long as you don't find the redef too magical, the following solution allows you to easily verify the function that's being partial'd as well as the arguments. Those tests all pass, and should provide security that the legally-drunk? and update-bac functions are sufficiently tested. The pure-legally-drunk? function still needs to be tested, but that should be easy since it's a pure function. Would you want this kind ## Recovering Lost Post Data DevFeed: [Recovering Lost Post Data]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-05-07T12:00:00Z Content type: tutorial Language: en Sources: [Jay Fields]() Topics: [Chrome](), [developer tooling](), [dry-run]() Tags: [chrome](), [devtools](), [dry-run](), [error](), [logging](), [network]() ### AI overview A practical guide to recovering form data after a session-expired error by using Chrome DevTools. It explains how to inspect the Network tab, find the POST request, allow a repost if prompted, and copy the contents of Form Data. ### Source excerpt I recently typed out a long, thoughtful response in a textarea. I clicked submit, like I've done millions of times, and I got the dreaded "session expired" error message. This happens very, very rarely, but it's devastating when it does. Creating long & thoughtful responses isn't something that comes naturally for me. I crossed my fingers and clicked back. No luck, web 2.0 dynamically created text boxes ensured Chrome had no chance to preserve my editing state. My first reaction was: I guess I'm not responding after all. Then it occurred to me, DevTools must have my data somewhere, right? Lucky for me, the answer was yes. There might be easier ways, this is what worked for me: open DevTools go to the "Network" tab. look for the row with the method POST. If you don't see a POST row, try refreshing the page. With any luck you'll get a repost confirmation dialog, giving you some hope that your data is still around. (You'll want to allow the data repost) click on the POST row, and scroll down till you see "Form Data". If you've gotten this far, hopefully you'll find your data in clear text and able to be copied. The examples from this post are from following the instructions above and logging in to twitter.com. If you've ever lost post data in the past, you may want to give these directions a dry-run now. © Jay Fields - www.jayfields.com ## Emacs Lisp: Toggle Between a Clojure String and Keyword DevFeed: [Emacs Lisp: Toggle Between a Clojure String and Keyword]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-05-02T14:41:00Z Content type: tutorial Language: en Sources: [Jay Fields]() Topics: [Emacs](), [ClojureScript](), [Refactoring](), [Lisp]() Tags: [clojure](), [conversion](), [emacs](), [emacs-lisp](), [refactoring](), [ruby](), [string]() ### AI overview This article presents an Emacs Lisp solution for toggling between Clojure strings and keywords, motivated by a refactoring task that required converting multiple Clojure keywords to strings. It also references a video demonstrating the behavior. ### Source excerpt When I was doing a fair bit of Ruby I often used the TextMate's shortcut (Ctrl+:) to convert a Ruby String to a Symbol or a Ruby Symbol to a String. It's something I've periodically missed while doing Clojure, and yesterday I found myself in the middle of a refactoring that was going to force the conversion of 5+ Clojure Keywords to Strings. The following emacs lisp is my solution for toggling between Clojure Strings and Keywords. The standard disclaimers apply - it works on my machine, and I've never claimed to know emacs lisp well. A quick video of the behavior: © Jay Fields - www.jayfields.com ## Year Five DevFeed: [Year Five]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-04-30T12:00:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [Job](), [Software Engineering](), [engineering-culture]() Tags: [clojure](), [developers](), [employment](), [experience-report](), [job](), [retention](), [software-engineering]() ### AI overview This experience report discusses why software developers may leave an employer after roughly three or four years. It describes perceived limits, familiarity with one's existing code and opportunities elsewhere, compensation differences, and the appeal of new challenges, while noting that the premise is speculative and based partly on personal observation. ### Source excerpt The average lifespan for a software engineering job is 4 years. Okay, I've never actually seen proof (or contradiction), but that's the general feeling in the groups I associate with. Perhaps that's selection bias - my employer has generally changed on year 3 or 4. Perhaps this is the exception and not the rule, in that case feel free to simply read this as an experience report. However, I do think it's somewhat common for developers to leave around year 3 or 4. This entry contains speculation on why they leave, and offers one idea on what employers can do to break that cycle. My 4 year employment cycle generally looks like this Year One: "I'm in over my head. My semi-bluff was in-fact a bluff. They're going to fire me any day." Year Two: "It's nice to feel like a productive team member" Year Three: "This is fun, and I'm not bad at it. It's satisfying to pass on knowledge to teammates." Year Four: "This feels repetitive, that grass over there sure looks greener" I expect that I, like many programmers, probably undervalue my contribution in the early days and overvalue my contribution in the latter days. In Year Three and Four at DRW I spent some time thinking about how I felt, and observing the behavior of some colleagues that were also on year three and four. A few things stood out to me. A company you don't work at always seems to have infinite possibilities; however, after a few years with an employer, it's extremely clear what your options are. More importantly, it's very clear what limitations will likely always be there. A company you don't work at contains no code you're responsible for. Conversely, any company you've been with for 4 years probably has plenty of code you're not proud of. If you're responsible for that code, it's a constant reminder of your previous limitations. If you're not responsible for it, your co-workers aren't likely to let you forget about it anytime soon. There's always someone willing to pay you more than you're worth. After several