Essays





2023   #74 - The Ambiguous Zone: It's easy for developers (me included!) to hide out at either end of a spectrum, on one end doing what we're told and on the other doing what we want. But real work happens in between these. (6 comments)

2022   #73 - The Fallacy of Splitting Time: If a developer is split across two projects, we often assume that each project will get one half of a developer worth of productivity, but in reality it's less. (2 comments)

   #72 - Going Solo and Dark Alleys: After twenty or so years as a software developer, mostly in consulting, I felt like I could handle myself in even the most tenuous situations. As an independent, it instantly felt different.

   #71 - Going Solo and the Loss of Bullshit: As a full-time employee, I used to loathe "bullshit". But after going independent, I learned there's a flip-side to it. (1 comments)

   #70 - Code Ownership, Stewardship, or Free-for-all?: As the pendulum has swung from monoliths to micro-everythings, we find ourselves with more "things" to build and maintain. And so it begs the question, who is responsible for what? (4 comments)

2021   #69 - Deleting Data in a Microservices Architecture: Deleting data within a microservices architecture can be more challenging than within a monolith, but there are different options. (10 comments)

   #68 - Always do Extra: A simple rule that every good, veteran programmer seems to follow with respect to managing their time. (25 comments)

   #67 - A Better Resume for Developers: Stuck in lock down with time on my hands and an itch to work on something new, I picked back up a side project I started about a decade ago, to build a better resume for developers. (10 comments)

2020   #66 - What do we Mean by "Rewrite" and "Refactor"?: We often frame our options as "rewrite or refactor", but these terms are really just stand-ins for a whole spectrum of choices (1 comments)

   #65 - The Risks of Rewrites: There's a deceptive allure to a rewrite, but they are subtly very difficult to pull off. Looking at the major risks. (4 comments)

   #64 - Why we Rewrite (Even When we Shouldn't): Examining the forces that nudge us toward a full-scale rewrite, even when it might not be the best choice. (6 comments)

   #63 - The Myth of Architect as Chess Master: The expectation for the architect should be to setup the framework or process by which good "moves" are made. (13 comments)

2019   #62 - Programming at a Big Company: The toughest problems to solve at big companies are often not the technical ones, but the social, political, and organizational ones. (5 comments)

   #61 - REST API Versioning with API-first and OpenAPI (Swagger): What's the best way to version a REST API when using OpenAPI and API-first?

   #60 - The Trouble with Tech Debt: Technical debt is a useful concept, but the definition has expanded to the extent that it's not always clear what it can and should refer to. (4 comments)

2018   #59 - First Ask Questions: When scoping out a project, it's helpful to first map out the terrain before trying to find the best route

   #58 - The Reality of Reuse: Overly optimistic expectation for the benefits and ease of reuse is one of the most pervasive and pernicious traps in software development (11 comments)

2017   #57 - Unclosed Loops and Developer Frustration: Why is it frustrating for developers to switch tasks mid-sprint? The Zeignarnik Effect is a cognitive bias that might explain. (7 comments)

   #56 - Batch Jobs in Clustered Environments: As much as we'd prefer to do everything in real time, there's often a need for batch processing. The question is, where do these go? (1 comments)

   #55 - Code Review Best Practices: In my opinion, code reviews are the "secret sauce" in a successful development process. Here are some best practices.

   #54 - Should I Care about the Alexa Platform? A Developer's View: In the past 6 months, Amazon is killing it with Alexa devices. Should developers jump on the bandwagon if they haven't already? (3 comments)

2016   #53 - Reflections of an "Old" Programmer: Framing our programming careers in terms of knowledge accumulation and decay can yield some interesting insights. (115 comments)

   #52 - The Agile Fantasy Draft: How does work get assigned on your team? A solution we've come up is the "fantasy draft", and it works pretty well. (4 comments)

   #51 - If you Speak Up, Speak First!: When a decision matters, it's important to be aware of cascades, both informational and reputational. (2 comments)

2015   #50 - Let's not be Slaves to Fashion: A standard theory of fashion states: people find ways to make themselves distinct in order to separate from the masses. How much of programming is fashion and how much function? (9 comments)

2014   #49 - The Siren Song of Automated UI Testing: Automated UI testing is not necessarily ineffective or a waste of time, but the promise land of easy, cheap, human quality testing via automation is a chimera. (14 comments)

2013   #48 - Code like a Champion Today: Do features in our physical environment affect the quality of our work? The science of psychological priming might suggest the answer is "yes". (3 comments)

   #47 - The 3 Motivational Forces of Developers: After 15 years in industry, I've come to realize that the most defining quality of a developer is his source of motivation. (28 comments)

   #46 - AI Challenge at the Summa Summit: At the Summa Summit this year, we tried out a new, hands-on coding activity that we dubbed 'Coding Spaces'. This is a recap of the AI Challenge I led.

   #45 - Expectations and the Endowment Effect: When setting expectations with the client, be aware of the endowment effect, which states that losses loom larger than gains. (2 comments)

   #44 - Consistency and Innovation: Pick One: When you find a better way of doing things in your code, what do you do? Use the new solution going forward, go back and refactor, or neither? (5 comments)

   #43 - Pair Programming - My Personal Nightmare: Pair Programming may work for some, but not for everyone (including me). Quality work can and is often done by people working quietly on their own. (83 comments)

   #42 - Keeping Code Clean with Cruft4J: I wrote a simple static code analysis tool which calculates how "crufty" Java code is, taking into account instances of complexity and copy-and paste.

2012   #41 - The User Interface and the Halo Effect: Understanding why minor user interface glitches carry such a high weight in terms of our customer's perception of quality. (23 comments)

   #40 - Velocity and Story Points - They don't add up!: I love the idea of velocity in theory, but in practice it's doomed to be dangerously inaccurate and imprecise on most every project. (10 comments)

   #39 - Time Zones and GWT's DateTimeFormat: A puzzler about GWT's DateTimeFormat and Time Zones - how tough could it be to display a birth date? (5 comments)

   #38 - 7 Tips for Exception Handling in GWT: There are a few tricks and gotchas that are important to be aware of when handling exceptions in GWT. (17 comments)

   #37 - Power Hour - an alternative to Pomodoro: Multi-tasking is the norm in most modern software development organizations, yet a number of studies have shown that it makes us much less effective.

   #36 - Usability Testing on Agile Projects (part 2): The second part of the series: how to perform the usability test and then use the results to affect change. (2 comments)

2011   #35 - Usability Testing on Agile Projects (part 1): Usability testing within agile projects from a project management perspective, describing how to estimate, prioritize, and "burn-down" the usability test.

   #34 - Getting Past the Deciders: Three tips for avoiding decision fatigue on enterprise software development projects. (5 comments)

   #33 - A Room Full of Techies: Understanding the phenomenon of group polarization in software development. (17 comments)

   #32 - 5 Tips for New Developers: A couple weeks ago, I came across a good post, "lessons for software industry novices", and it inspired me to add a few more just for the hell of it. (1 comments)

   #31 - Modeling Reference Data in the Application Tier: Designing data structures for reference data in the application tier can be tough, mostly because what we mean by "reference data" isn't always consistent. (6 comments)

   #30 - An Agile Dilemma - How to start the Sprint: Six strategies for jumping into the sprint, and getting started with your tasks. (7 comments)

   #29 - Developers - How do you manage your to-dos?: There are days when my brain is literally over-flowing with things I have to do, and around every corner lies something new. How do you manage it all? (2 comments)

   #28 - A pattern for GWT code splitting: A simple pattern using the GWT 2.1 MVP framework for implementing code splitting for optimization purposes. (5 comments)

   #27 - Structuring GWT modules for large applications: It's not always clear when designing GWT applications whether one, two, or more modules should be created. (18 comments)

2010   #26 - Parallel asynchronous calls in GWT: A pattern for making asynchronous calls in parallel using GWT. (20 comments)

   #25 - Beyond Role-Based Access Control: Most often authorization is managed via simple roles, but seldom does this meet all the requirements of the business. (1 comments)

   #24 - The Problems of Decentralized Authorization: The status quo for enterprise authorization, decentralization, is fraught with problems. There's a way out though!

   #23 - An Architect's Morality: What's the best path to good judgement for an architect - via experience or reasoning? (1 comments)

   #22 - Collective Code Ownership and Craftsmanship: Agile methodologies hinge on a model of collective code ownership. But does this allow for craftsmanship or pride of ownership? (1 comments)

   #21 - Keep it Simple!: Cognitive fluency is the theory that things that are easier to think about seem to be more true, intelligent, and likeable. What this means for programmers.

   #20 - Usability, RIA, and GWT - 6 Questions to Ask your Users: Before jumping in and developing applications with GWT, there are a few things you need to know from your users first. (5 comments)

2009   #19 - Using Code Metrics with Purpose: To glean any strategic benefit, code quality tools must be used with fore-thought.

   #18 - SOA and Authorization: What's so hard about it anyway?: As usual, the new SOA paradigm adds some new complexity to old problems, like Authorization. (5 comments)

   #17 - Anchors Away!: How can a developer communicate an honest, but high, estimate to management? Try the concept of an anchor, from behavioral economics. (21 comments)

   #16 - What is 'Good' Software Architecture?: Can "good" architecture be defined in purely pragmatic terms? If the system fulfills the needs of the person or organization who funds its existence, it's successful ipso facto! (7 comments)

   #15 - 6 Tips for Managing Property Files with Spring: Managing property files in an enterprise application is not always as easy as it would seem. (43 comments)

   #14 - SOA and the N + 1 Selects Problem: The classic N + 1 Selects problem rears its head in the new world of SOA. (10 comments)

2008   #13 - Building a Better Resume for Developers: The developer resume is broken. It's dense. It's long. It's static. I recently built something better - I hope! (9 comments)

   #12 - The Code Review Potluck: Fagan-style code reviews do work, but seldom do we have the time or discipline to actually do them regularly. There is another way. (4 comments)

   #11 - Does Programming to Interfaces Buy Us Anything?: Most often, coding to interfaces is just dogmatically applied, adding to code bloat and developer frustration and providing very little real value. (24 comments)

   #10 - Deliberative Development: Silo development has it's advantages, namely speed. But political philosophy's Deliberative Democracy has something to say about the negative consequences. (10 comments)

   #9 - 7 Strategies for Unit Testing DAOs and other Database Code: Creating repeatably passing unit tests for an enterprise application is hard work, mostly because of the reliance on volatile data. Here are 7 common approaches for testing database code. (12 comments)

   #8 - Politics and Programming: We as programmers have beliefs about software development. We as citizens have beliefs about government. Is there any connection or correspondance between the two?

   #7 - The Architect's Dilemma: There's a natural tension between the philosophies of up-front design (BDUF) and in-time design (YAGNI). Can decision trees help? (5 comments)

   #6 - Managing Code Quality with PMDReports: Introducing my pet project, PMDReports, for managing code quality. (2 comments)

2007   #5 - Why are our Programming Gods so Unkempt?: Does a theory of finite will-power say anything about our software Gods, or the environment we work within? (2 comments)

   #4 - Is it Irrational to Comment your Code?: We know we should comment code, but will we? Game Theory's Prisoner's Dilemma says, "probably not". (8 comments)

   #3 - Why Code Quality Tools Work: Using rational choice theory to explain why PMD, CheckStyle, and other code quality tools work in the real world. (1 comments)

2006   #2 - Starting a Design Patterns Discussion Group: Once upon a time, I started a design patterns discussion group to slog through that distinguished blue and white book that decorated my bookshelf. Here are my lessons learned.

   #1 - The Search for a Good UML Tool: When we want a UML tool, it's most often to help us either design, understand, or maintain. There are a lot of tools out there, and all are not created equal.

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!