DaedTech

Stories about Software

By

The Hidden Costs of Slow Websites

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at all of the different monitoring solutions they offer.

The world seems to conceive of a curious bubble separating IT from “the business.”  More so than just about any other pursuit in the commercial world, people think of IT as some kind of island.

It thus becomes easy to conceive of IT goals existing in a vacuum.  “We should optimize the database so that it becomes better.”  “We should make this software work on all platforms.”  The part about “… because that will help us make money” seems never to materialize.

Agile methodologies like Scrum seek to address this separation by encouraging tight interaction between IT and business interests.  Doing this closes the loop between technical actions and profit motives.  “We should make this software work on all platforms in order to increase revenue by 50%.”

If we look at the world of company websites, we can find the ubiquitous argument for faster page load times.  “The site should load faster.”  Today, I’d like to make the business case for why we want this.

But I’d like to dig a little deeper than the most obvious cost.  To understand that, consider articles like this one.  Users tend to bounce in the face of multi-second page loads.  As a result, slow performance could cost a high-throughput giant like Amazon billions of dollars.

I doubt that news shocks you.  So, instead, let’s take a look at more subtle ways that your business can lose money via a slow site.  Let’s examine hidden costs of slow websites.

Read More

By

How to Freelance: The Low-Risk Path from Software Developer

Ah, the eternal opportunistic question: how to freelance?  You work as a software developer, making $100K per year or something.  This is a great wage, and so you have a great life, sitting pretty high up atop Maslow’s famed hierarchy.  But then you figure out that Steve in your group is actually a contractor, and a little later, you figure out that they pay Steve $70 per hour.  A quick google search for “work hours per year” and fast math tell you that Steve makes $145,600 per year (so you think, anyway).  Suddenly, you feel less like a prosperous citizen and more like a sucker.

How to Freelance like Steve and make big money

How can I get some of that Steve money?

Not far behind that thought comes another.  I should become a contractor!  And then, finally, we get back to the titular concern: how to freelance?

The Reader Question and Some Housekeeping

As regular readers may have deduced, I’m doing a reader question today.  And, as regular readers may have noticed, I haven’t done reader questions (or DaedTech-only posts) in a while.  Please forgive me on that count.  I spent a lot of writing energy on my recent book launch and then even more on starting a tech company blogging business.  With all of that writing, I’ve had trouble mustering spare writing cycles the last few weeks.

But I’m turning a corner on that and launching the first of what will be a series: “reader question Fridays.”  I’m making the vision of this site more and more oriented around the Developer Hegemony vision (software developers becoming the bosses of software development), so please fire away with questions.  I take all comers, but I’ll prioritize questions that speak to the subject of software developer agency.

Anyway, I’ll paraphrase the reader question.

I currently work as a salaried software developer.  I think I’d like to figure out the freelance thing, but I’m not sure.  It’d mean a lot of risk to quit my job and hang out my shingle, so I’m wondering what you advise to make this a less risky transition.

I actually wrote about a related topic recently.  But that question more concerned my personal background and how to become a consultant.  Freelance software development is not, in my opinion, consulting.  I refer to people who do that as software pros.  Firms pay consultants for their opinions and they pay software pros for their labor.  I draw the distinction here because software pros need to worry a lot less about specializing and niching — at least at first.

But forget about the taxonomy and let’s look at how to become a freelance software developer with a low risk playbook.

Read More

By

Software Craftsmanship is Good Business

Tonight, I logged into my site and saw a picture of someone’s colon, compliments of everyone’s favorite NSFW advertising engine, Disqus.  (Read more about this here).  Enough is enough, so I switched commenting engines.  Please bear with me and let me know if you have issues with comments.

On a less aggravating note, please enjoy post number 4 of Developer Hegemony week!  Pre-launch activities are progressing nicely, and I’m looking forward to the launch.  If you’d like a free paperback copy of the book, remember to sign up for the Thunderclap.IT campaign so that we can get to the sharing threshold — we’re halfway there, but I still need your help.  It only takes a second.

I feel as though I’d like to balance the scales a bit.  Lately, I’ve made a lot of realpolitik posts about how organizations cast software developers as grunts.  This is true, but also depressing.  So let’s talk about the uplifting alignment between well reasoned code and success in career and business.

Raw Programmer Skill and Diminishing Marginal Returns

First of all, I should point out that I talk a good bit about the diminishing marginal returns of programming skill, both in posts and in Developer Hegemony.  And I stand by that.  To understand why, I invite you to do a thought exercise with me.

I’m pretty sure that most of you programmers reading, if you were so inclined, could go out and find a new job within a few weeks.  And, what’s more, you could probably negotiate a 5% pay increase to switch.  Did you suddenly become 5% better at programming?  Or would you acknowledge that programmer pay doesn’t necessarily correlate simply with programmer skill?

The industry isn’t meritocratic.  Of course, the industry is also not anti-meritocratic.  Rather, if programmer skill and programmer pay had a mutual Facebook relationship status, they would choose it’s complicated.

I would further reinforce the point about diminishing returns.  Go from zero to decent programmer and you might go from 30K per year for non-degreed work to $90K per year for programming.  Go from decent to highly skilled, and you can climb to $120K, which feels less life-changing.  Beyond $120K, your increased skills help you not a lick at puncturing the software developer’s glass ceiling.  Diminishing returns on skill investment.

Good vs Valuable

But don’t despair.  Winning programming “contests” and algorithm trivia jousts won’t pay off, but that doesn’t mean that you can’t make your software career pay off.  You just need to understand what businesses value.

So far, all we’ve done is figure out what they don’t value.  Namely, they don’t value journeyman idealist pissing contests.  The company will say, “it’s great that you can write a compiler on the back of a napkin and have it work flawlessly the first time it’s transcribed and run, but I only want that within the Software Engineer IV salary band.”  The company doesn’t value this prodigious industry cred the way your peers do.

And why should they?  If the company sells cable modems, how does that compiler help them?  “I can see that you’re quite good, but we don’t find this valuable.”

The trick then becomes establishing yourself as valuable.  And, while valuable and good have a deeply intertwined relationship, you cannot simply interchange them.  I submit that the software craftsmanship ideal offers you a ready-made playbook for turning good into valuable.

Read More

By

Managing Risk via Static Analysis

Editorial Note: I originally wrote this post for the NDepend blog.  Check out the original here, at their site.  While you’re there, take a look at the features of NDepend and download a trial, if you’re so inclined.

When software developer talk about static analysis, it’s often in the context of craft improvement.  Ask most developers in a group about static analysis tools and you’ll get a range of responses, many of which will be fueled by some degree of passion, resulting from past experience.  From here, the conversation will tend to dive into the weeds for any non-technical stakeholder that might be listening; if you’re not a programmer, you probably don’t have much of an opinion as to whether or not cyclomatic complexity of 5 is acceptable for a method.

As a result, static analysis tends to get pegged heavily as a purely a matter of shop.  The topic tends to be pretty opaque to management because developers present it to them in terms of “this will make us better and the code better.”  Management that trusts the developers will tend to agree to the purchase with a sentiment of, “okay, I’ll take your word for it.”  Management that is more skeptical says, “maybe next year if our numbers are good.”

I find this to be a shame because it’s a lost opportunity, even when management agrees.

Static analysis most certainly is a way for developers to improve their craft and their codebases.  But, in the hands of an architect or team lead that truly understands the business and works well with management, static analysis can be an excellent tool for managers, even if the use has to be a management-architect team effort.

How so?  Well, there are a lot of ways, but the one I’d like to mention today is risk management.  As the title would imply, managing risk tends to be the purview of people whose title is manager.  Sure, the developers have responsibility for this, but their primary charter is to build stuff — management exists specifically to engage in planning activities, including the crucial concern of risk management.

How does this work?  Well, I’ll show you, and I’ll do it by explaining the sort of highly technical things that static analysis could catch in highly non-technical and readable ways.  These are all going to be operational risks — static analysis can’t help you if you’re building the wrong product or badly under-staffing your projects.  But it can help you avoid landmines in your software.  If you’re a manager, allow me, for the moment, to serve as your “business-savvy architect.”

Architect

Read More

By

Calculating the ROI of NDepend

Editorial note: I originally wrote this post for the NDepend blog.  Head over to their site and check out the original.  While you’re there, take a look at the other posts and the offering to be had.

Years ago, I discovered NDepend and downloaded it for a trial.  At the time, I found myself working in a .NET shop where a lot of developers worked in the same large WPF codebase.  Code reviews were mandated, debates were frequent and impassioned, and global variables were everywhere, to the dismay of only some of us.  There was an entrenched majority that favored (or at least didn’t mind) a highly procedural style of writing object-oriented software, and nobody seemed able to put their fingers on why most feature development there had slowed to a crawl.

ScaryComputer

I was new to the group and had to pick my battles, particularly with people that had been there a long time.  Developers who favored automated testing and craftsmanship principles were in the minority there and had a history of leaving out of frustration, so I knew it’d be a challenge, and I went looking for help.  Among other things, I found NDepend and, after installing a trial, I recognized the power of the tool.

I recognized that it could help me as an objective, unbiased partner in making my arguments, but I also recognized that the way I approached code and architecture would never be the same.  The ability to visualize architecture in real time, the ability to treat code as queryable data, the metrics, the statistics, the well thought-out code warnings… it was a game-changer for me.  I just needed to convince my manager to let me spend a few hundred dollars to convert my trial version into a paid version.

It turned out this wasn’t hard, at least for me.  I had the good fortune of working for a company that appropriated a tools and learning budget for each individual developer, meaning all I had to do was declare that I wanted some of my total spend to go toward NDepend.  I did it without blinking.  But it might be that you aren’t as lucky.  Maybe you find yourself in a similar position to mine back then, but wanting to convince your manager that this powerful tool is indispensable because you don’t have a discretionary tools budget.

ROI: The Language of Management

I think I can help you here.  After all, I did leverage my experience running an IT department into a Plurlasight course about how to lobby your managers for practices and tools.  And the key to making a business case for anything, NDepend included, is to talk in terms of profits and losses, rather than in terms of, “it’s awesome, and it has all these graphs, and it shows me these rules, and CQLinq is the coolest thing ever, and…”  You get the idea.  NDepend’s coolness factor isn’t going to convince your manager to buy it for you.

Read More