| 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.
