DaedTech

Stories about Software

By

Making Money through Tech Blogs

It’s reader question Monday again.  Lately, I’ve been talking a lot about entrepreneurial topics or about topics related to Developer Hegemony.  But today, I’ll answer a different flavor of reader question.  This one is about tech blogs.  Or, more specifically, it’s about how owners of tech blogs should price things.

I was recently asked by a well known company to review a product of theirs on my site and they offered to pay me for my efforts.

I actually said I’d do it and then they could pay me what they thought it was worth. I’m not sure that was the best idea as I haven’t heard back from them!

I find researching products and writing about them is the best way to learn and getting paid to do it would be a bonus. As you frequently blog for various sites, how do you price your services out? How do you invoice them? What else do I need to know to get started in this area?

Thanks for your time and your blog posts.

Well, first of all, you’re welcome.  Thank you for reading them!

Given that I’ve done a fair bit of tech blogging over the years, and that I’ve founded a tech blogging business (we’re looking for authors!), I can certainly speak to this.  To do that, let’s do this.  I’ll walk through the progression of money making opportunities that you’ll likely encounter as a tech blogger.

Making money through tech blogs can make it seem like money is pouring out of your monitor.

Read More

By

The ROI for Security Training

When it comes to IT’s relationship with “the business,” the two tend to experience a healthy tension over budget.  At the risk of generalizing, IT tends to chase promising technologies, and the business tends to reign that in.  And so it should go, I think.

The IT industry moves quickly and demands constant innovation.  For IT pros to enjoy success, they must keep up, making sure to constantly understand a shifting landscape.  And they also operate under a constant directive to improve efficiency which, almost by definition, requires availing themselves of tools.  They may write these tools or they might purchase them, but they need them either way.  In a sense, you can think of IT as more investment-thirsty than most facets of business.

The business’s leadership then assumes the responsibility of tempering this innovation push.  This isn’t to say that the business stifles innovation.  Rather, it aims to discern between flights of fancy and responsible investments in tech.  As a software developer at heart, I understand the impulse to throw time and money at a cool technology first and figure out whether that made sense second.  The business, on the other hand, considers the latter sensibility first, and rightfully so.

A Tale of IT and the Business

Perhaps a story will serve as a tangible example to drive home the point.  As I mentioned, my career background involved software development first.  But eventually, I worked my way into leadership positions of increasing authority, ending up in a CIO role, running an IT department.

One day while serving in that capacity, the guy in charge of IT support came to me and suggested we switch data centers.  I made a snap judgement that we should probably do as he suggested, but doing so meant changing the budget enough that it required a conversation with the CFO and other members of the leadership team.

Anticipating their questions and likely pushback, I asked the IT support guy to put together a business case for making the switch.  “Explain it in terms of costs and benefits such that a non-technical person could understand,” I advised.

This proved surprisingly difficult for him.  He put together documentation talking about the relative rates of power failures, circuit redundancy, and other comparative data center statistics.  His argument in essence boiled down to one data center having superior specs than the other and vague proclamations about best practices.

I asked him to rework this argument, suggesting he articulate the business case using sort of a mad lib: “If we don’t make this change, we have a ______% chance of experiencing problem _______, which would cost $_______.”

This proved much more fruitful. We made the case to the CFO and then made the switch.

Read More

By

What Is Performance Testing? An Explanation for Business People

Editorial note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, take a look at their comprehensive solution for gaining insight into your application’s performance.

The world of enterprise IT neatly divides concerns between two camps: IT and the business.  Technical?  Then you belong in the IT camp.  Otherwise, you belong in the business camp.

Because of this division, an entire series of positions exists to help these groups communicate.  But since I don’t have any business analysts at my disposal to interview, I’ll just bridge the gap myself today.  From the perspective of technical folks, I’ll explain performance testing in language that matters to the business.  And, don’t worry.  I’ve spent enough years doing IT management consulting to have mostly overcome the curse of knowledge.  I can empathize with anyone understanding performance testing only in the vaguest of terms.

A Tale of Vague Woe

To prove it, let me conjure up a maddening hypothetical.  You’ve coordinated with the software organizations for months.  This has included capturing the voice of the customer and working with architects and developers to create a vision for the product.  You’ve seen the project through conception, beta testing and eventual production release.  And you’re pretty proud of the way this has gone.

But now you find yourself more than a little exasperated.  A few scant months after the production launch, weird and embarrassing things continue to go wrong.  It started out as a trickle and then grew into a disturbing, steady stream.  Some users report agonizingly slow experiences while others don’t complain.  Some report seeing weird error messages and screens, while others have a normal experience.  And, of course, when you try to corroborate these accounts, you don’t see them.

You inquire with the software developers and teams, but you can tell they don’t quite take this at face value.  “Hmmm, that shouldn’t happen,” they tell you.  Then they concede that maybe it could, but they shrug and say there’s not much they can do unless you help them reproduce the issue.  Besides, you know users, amirite?  Always reporting false issues because they have unrealistic expectations.

Sometimes you wonder if the developers don’t have the right of it.  But you know you’re not imagining the exasperated phone calls and negative social media interactions.  Worse, paying users are leaving, and fewer new ones sign up.  Whether perception or reality, that hits you in the pocketbook.

Read More

By

How to Evaluate Your Static Analysis Process

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 a trial of NDepend and take a look at its static analysis capabilities.

I often get inquiries from clients and prospects about setting up and operationalizing static analysis.  This makes sense.  After all, we live in a world short on time and with software developers in great demand.  These clients always seem to have more to do than bandwidth allows.  And static analysis effectively automates subtle but important considerations in software development.

Specifically, it automates peer review to a certain extent.  The static analyzer acts as a non-judging, mute reviewer of sorts.  It also stands in for a tiny bit of QA’s job, calling attention to possible issues before they leave the team’s environment.  And, finally, it helps you out by acting as architect.  Team members can learn from the tool’s guidance.

So, as I’ve said, receiving setup inquiries doesn’t surprise me.  And I applaud these clients for pursuing this path of improvement.

What does surprise me, however, is how few organizations seem to ask another, related question.  They rarely ask for feedback about the efficacy of their currently implemented process.  Many organizations seem to consider static analysis implementation a checkbox kind of activity.  Have you done it?  Check.  Good.

So today, I’ll talk about checking in on an existing static analysis implementation.  How should you evaluate your static analysis process?

Read More

By

How Much Unit Testing is Enough?

Editorial note: I originally wrote this post for the TechTown blog.  You can check out the original here, at their site.  While you’re there, have a look at their training and course offerings.

I work as an independent consultant, and I also happen to have created a book and some courses about unit testing.  So I field a lot of questions about the subject.  In fact, companies sometimes bring me in specifically to help their developers adopt the practice.  And those efforts usually fall into a predictable pattern.

Up until the moment that I arrive, most of the developers have spent zero time unit testing.  But nevertheless, they have all found something to occupy them full time at the office.  So they must now choose: do less of something else or start working overtime for the sake of unit testing.

This choice obviously inspires little enthusiasm.  Most developers I meet in my travels are conscientious folks.  They’ve been giving it their all and so they interpret this new thing that takes them away from their duties as a hindrance.  And, in spite of signing a contract to bring me in, management harbors the same worry.  While they buy into the long term benefit, they fret the short term cost.

All of this leads to a very predictable question.  How much unit testing is enough?

Clients invariably ask me this, and usually they ask it almost immediately.  They want to understand how to spend the minimum amount of time required to realize benefits, but not a second longer.  This way they can return to the pressing matters they’ve delayed for the sake of learning this new skill.

Read More