DaedTech

Stories about Software

Nov
20

By

With or Without the US, The Future of Tech is Globalism

Category: The Life of a Programmer Tags: | 8 Comments

I spent most of August, September, and October on the road for work.  I then capped that with a celebratory vacation week in Panama, exploring cities, beaches and jungles.  As luck would have it, this also allowed me to miss the acrimony and chaos of the national US elections.

Earlier this week, I returned to a country in which Donald Trump had pulled of a surprising upset, causing the world to scramble to adjust its mental model of the coming 4 years.  The night of the election alone, markets plummeted and then subsequently rallied.  In the time since, people all over the world have furiously tried to make sense of what the development means for them.

Quick Disclaimer

I personally find partisan politics (at least in the US — I can’t speak as well for other countries) to resemble rooting for sports teams.  Americans decide, usually based on their parents’ loyalties, to root for The Republicans or The Democrats, and they get pretty upset when their team loses and the other team wins, ala fans of the Boston Red Sox and the New York Yankees.  Think of partisan US politics as like baseball, except the winner of the World Series gets to declare wars and approve federal budgets.

baseball-player

So as an entrepreneur and someone with a readership of unknowable team loyalty distribution, it behooves me not to choose sides, notwithstanding my own political beliefs (though, for the record, I don’t view politics as a spectator sport and so I genuinely have no home team loyalty).  I try to remain publicly, politically neutral.  And I will do my best to do so in this post, even as I talk about a theme heavily informed by US politics.

The Beginning of a Tech Dispersion

Specifically, I want to talk today about what this election means for the future of tech.  As a free agent and entrepreneur, I monitor relevant events more closely than most, looking for opportunities and warning signs.  And I think this unexpected outcome of the US election presents both opportunities and warning signs for software developers and technologists.

I believe the US has charted a course away from its status as a global technology leader and that the next decade will reveal opportunities for other countries to fill any resultant void.  The world constantly looks for “the next Silicon Valley.”  It should start looking for this in other countries.

I’m going to lay out in this post why I think this, and I’m going to do it without value judgment editorializing (or try my best, anyway).  And then I’m going to talk about what I think this means for people that earn a living writing software or making technology.  How do you prepare for and capitalize on a less US-centric techie world?

So, first up, the why.  Why do I say that the US role in global technology will become de-emphasized during a Trump presidency?  Caveat emptor.  I could be totally wrong about all of this, but the plays I suggest are ones I plan to make, so I will put my money where my mouth is.

Read More

Nov
17

By

Should You Review Requirements and Design Documents?

Category: The Life of a Programmer Tags: , | 2 Comments

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  While you’re there, have a look around at posts and knowledge from other authors.

I remember working in a shop that dealt with medical devices some years back.  I can’t recall whether it was the surrounding regulatory requirements or something about the culture at this place, but there was a rule in place that required peer review of everything.

Naturally, this meant that all code was reviewed, but it went beyond that and extended to any sort of artifact produced by the IT organization.  And, since this was a waterfall shop, that meant review (and audit-trails of approval) of the output of the requirements phase and the design phase, which meant requirements and design documents, respectively.  I can thus recall protracted meetings where we sat and soberly reviewed dusty documents that made proclamations about what “the system” shall and shan’t do.  We also reviewed elaborate sequence, flow, hierarchy, and state design artifacts that were probably obsolete before we even reviewed them.

If I make this activity sound underwhelming in its value, that’s because I routinely felt underwhelmed by its value.  It was a classic case of process over common sense, of ceremony over pragmatism.  Everyone’s attention wandered, knowing that all bets would be off once the development started.  Sign-offs were a formality — half-hearted and cursory.

But is it worth throwing the baby out with the bathwater?  Should the fact that waterfall shops waste time on and around these documents stop you from producing them and subsequently reviewing them?  Is it worth reviewing requirements and design documents?

LotsLeftToDo

Read More

Nov
15

By

How to Deliver Software Projects on Time

Category: The Life of a Programmer Tags: | 2 Comments

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download NDepend and give it a try.

Someone asked me recently, almost in passing, about the keys to delivering software projects on time.  In this particular instance, it was actually a question of how to deliver .NET projects on time, but I see nothing particularly unique to any one tech stack or ecosystem.  In any case, the question piqued my interest, since I’m more frequently called in as a consultant to address issues of quality and capability than slipped deadlines.

To understand how to deliver projects on time (or, conversely, the mechanics of failing to deliver on time) requires a quick bit of term deconstruction.  The concept of “on time” consists of two concerns of software parlance: scope and delivery date.  Specifically, for something to be “on time” there has to be an expectation of what will be delivered and when it will be delivered.

Clipboard

How We Get This Wrong

Given that timeliness of delivery is such an apparently simple concept, we sure do find a lot of ways to get it wrong.  I’m sure that no one reading has to think long and hard to recall a software project that failed to deliver on time.  Slipped deadlines abound in our line of work.

The so-called “waterfall” approach to software delivery has increasingly fallen out of favor of late.  This is a methodology that attempts simultaneously to solve all unknowns through extensive up-front planning and estimation.  “The project will be delivered in exactly 19 months, for 9.4 million dollars, with all of the scope outlined in the requirements documents, and with a minimum standard of quality set forth in the contract.”  This approach runs afoul of a concept sometimes called “the iron triangle of software development,” which holds that the more you fix one concern (scope, cost, delivery date), the more the others will wind up varying — kind of a Heisenburg’s Uncertainty Principle of software.  The waterfall approach of just planning harder and harder until you get all of them right thus becomes something of a fool’s errand.

Let’s consider the concept of “on time” then, in a vacuum.  This features only two concerns: scope and delivery date.  Cost (and quality, if we add that to the mix as a possible variant and have an “iron rectangle”) fails to enter into the discussion.  This tends to lead organizations with deep pockets to respond to lateness in a predictable way — by throwing resources at it.  This approach runs afoul of yet another aphorism in software known as “Brooks’ Law:” adding manpower to a late software project makes it later.

If we accept both Brooks’ Law and the Iron Triangle as established wisdom, our prospects for hitting long range dates with any reliability start to seem fairly bleak.  We must do one of two things, with neither one being particularly attractive.  Either we have to plan to dramatically over-spend from day 1 (instead of when the project is already late) or we must pad our delivery date estimate to such an extent that we can realistically hit it (really, just surreptitiously altering delivery instead of cost, but without seeming to).

Read More

Nov
6

By

The Developer Feedback Loop

Category: The Life of a Programmer Tags: , | 2 Comments

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, check out some of the products that they offer, including GhostDoc and CodeIt.Right.

If you write software, the term “feedback loop” might have made its way into your vocabulary.  It charts a slightly indirect route from its conception and into the developer lexicon, though, so let’s start with the term’s origin.  A feedback loop in general systems uses its output as one of its inputs.

Kind of vague, huh?  I’ll clarify with an example.  I’m actually writing this post from a hotel room, so I can see the air conditioner from my seat.  Charlotte, North Carolina, my temporary home, boasts some pretty steamy weather this time of year, so I’m giving the machine a workout.  Its LED display reads 70 Fahrenheit and it’s cranking to make that happen.

When the AC unit hits exactly 70 degrees, as measured by its thermostat, it will take a break.  But as soon as the thermostat starts inching toward 71, it will turn itself back on and start working again.  Such is the Sisyphean struggle of climate control.

TerrifiedOfFurnace

Important for us here, though, is the mechanics of this system.  The AC unit alters the temperature in the room (its output).  But it also uses the temperature in the room as input (if < 71, do nothing, else cool the room).  Climate control in buildings operates via feedback loop.

Appropriating the Term for Software Development

It takes a bit of a cognitive leap to think of your own tradecraft in terms of feedback loops.  Most likely this happens because you become part of the system.  Most people find it harder to reason about things from within.

In software development, you complete the loop.  You write code, the compiler builds it, the OS runs it, you observe the result, and decide what to do to the code next.  The output of that system becomes the input to drive the next round.

If you have heard the term before, you’ve probably also heard the term “tightening the feedback loop.”  Whether or not you’ve heard it, what people mean by this is reducing the cycle time of the aforementioned system.  People throwing that term around look to streamline the write->build->run->write again process.

Read More

Oct
25

By

API Design Using Behavior Driven Development

Category: The Life of a Programmer | 4 Comments

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  While you’re there, take a look at some of their products in the code review, testing, and API spaces.

Test-driven development (TDD) has been around for a while now.  Behavior-driven development (BDD) is a comparably recent methodology that emerged from the practice of TDD.  It could reasonably be called a narrower application of TDD.

TDD is a process where one uses a failing unit test to express a shortcoming of the system.  The next step is then to modify the production code to get the failing test to pass, without making existing tests fail.  BDD more or less takes this same concept and adds to it the idea that the tests should be written in easy-to-understand language about the problem domain, and that they should express user acceptance criteria.

So instead of

void testErrorMessageOnNull()

you would have

Given a text box that has been left empty, when I click submit, I should receive an error message.

As a practice, this has found its way into the agile canon, and given rise to something conversationally termed, “three amigos.”  This is a practice wherein a representative of “the business,” a tester, and a developer get together and agree on what a requested feature is, what it means, what it looks like when done, and how to verify completion.  In teams practicing BDD, the output of this conversation will often be an acceptance test, expressed in the Gherkin specification language.  When added to the codebase, this test will, of course, fail.  The folks implementing the feature know that they’re done when they’ve succeeded in making the test pass.

three-amigos

If we put agile aside for a minute, this is a pretty common sense approach for any team.  The essence of it is, “let’s define and be clear about what success looks like and then automate a check for it.”  So you don’t need to be an agile team for this to make sense — you just need to be a team looking for clarity.

Read More

« Older Posts
Newer Posts »