DaedTech

Stories about Software

Oct
8

By

The Merits and Ethics of Learning on the Job in App Dev

Category: You Asked For It Tags: , , |

Another Monday, another successful reader question Monday.  Today’s question is about learning on the job.  Let’s take a look.

This is more of an app dev shop question than a consulting question, but here goes.

Say you’re consulting for a client and the client has a specific need for some app dev work which they ask you to do. That work requires you to use a technology that’s either completely new to you, not quite in your line of specialty, or you haven’t used in several years, but you’re constrained in some way to use this technology and to do the project you would need to “ramp-up”.

The question is: do you bill the client for this “ramp-up” time or do you take the hit against your own personal time to come up to speed? Does it make a difference in the response if it’s a legacy technology that you may never use again (FORTRAN) vs. a “hot” language that it would benefit you to learn (Python)?

First of all, for everyone else, here’s what the reader is referring to about consulting vs. app dev.  I’ve written a good bit about how writing software for someone else isn’t “consulting” no matter what people might call it.  So the question concerns either app dev shops or app dev freelancers.

Learning on the Job

Learning on the Job: The Quick Answer

I’ll start by answering the question at the tactical level.  Should you bill for this ramp-up time?  Absolutely, as long as you can negotiate it and you do so in good faith.

The last time I agreed to app dev work, I dealt with something like this.  I’d worked with the client before, and they liked my work.  I had domain knowledge and we had a good rapport, so they engaged me for some work.  I told them that I had to learn an important technology as I went, and they were fine with this added cost.  They viewed it as worth it.

Contrast this with a different situation.  Imagine you’re a Ruby on Rails developer and you need some work.  So you answer an RFP for help with an ASP MVC site, knowing nothing about ASP MVC but claiming you’re competent.  That’s pretty much the opposite end of the spectrum, and obviously problematic.

So start with the requirement that you’ll be frank about anything you need to learn to execute on an engagement.  The matter of who bears the cost of that learning then becomes a matter of negotiation as part of the contract.  And, that should make sense, since you’ll always have to learn something to help a client.  If you need the gig more than they need you, you might need to spend unpaid evenings learning a framework.  If they really need you and you’re on the fence, you can require that they include your onboarding as part of the deal.

Read More

Oct
5

By

The Importance of Performance on the Development Side

Category: Language Agnostic Tags: , | 7 Comments

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 their offering for monitoring your software in production.

In the software development world, we pay a ton of attention to the performance of our code in production.  And rightfully so.  A slow site can make you hemorrhage money in a variety of ways.

To combat this, the industry has brought some of its most impressive thinking to bear.  The entire DevOps movement focused on bringing things to production more efficiently and then managing it more efficiently.  Modern software development emphasizes this, staffs for it, and invests in it.

But looking beyond that, we leverage powerful tools.  Monitoring solutions let us get out in front of problems before users can discover them.  Alerting solutions allow us to configure those solutions to happen more effectively.  Entire organizations and industries has sprung up around creating seamless SaaS experiences for end users.

But in spite of all this, I’ve found that we have a curious blind spot as an industry.

A Tale of Misery

Not too long ago, I sat in a pub having a beer, waiting on my food to arrive.  With me sat a colleague that works for a custom app dev agency.  In this capacity, he visits clients and works on custom software solutions in their environments.

Over our beers, he described their environment and work.  They had some impressive development automation.  This included a continuous integration setup, gated builds, and push-button or automated deployments to various environments.  And once things were in production, they had impressive instrumentation for logging, tracking, and alerting about potential issues.

I told him that he was lucky.  He countered in a way that caught me a bit off guard.  “Yeah, it’s impressive, but actually working there as a developer is pretty rough.”

I asked him to clarify, so he did.  He told me about having to use slow, old development machines.  He talked about unit test suite runs taking forever locally and even longer in the build environments.  They had a lot of best practices in place, but actually getting anything done was really hard.  Even the source control server was flaky, sometimes kicking back attempted commits and creating issues.

This struck me as a fascinating contrast.

Read More

Oct
4

By

Should You Aim for 100 Percent Test Coverage?

Category: Language Agnostic Tags: , , | 8 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, check out all of the different code metrics and rules that NDepend offers.

Test coverage serves as one of the great lightning rods in the world of software development.  First, people ask whether it makes for a good metric at all.  Then they ask, if you want to use it as a metric, should you go for 100 percent coverage?  If not, what percentage should you go for? Maybe 42 percent, since that’s the meaning of life?

I don’t mean to trivialize an important discussion.  But sometimes it strikes me that this one could use some trivializing.  People dig in and draw battle lines over it, and counterproductive arguments often ensue.  It’s strange how fixated people get on this.

I’ll provide my take on the matter here, after a while.  But first, I’d like to offer a somewhat more philosophical look at the issue (hopefully without delving into overly abstract navel-gazing along the lines of “What even is a test, anyway, in the greater scheme of life?”)

What Does “Test Coverage” Measure?

First of all, let’s be very clear about what this metric measures.  Many in the debate — particularly those on the “less is more” side of it — quickly point out that test coverage does not measure the quality of the tests.  “You can have 100 percent coverage with completely worthless tests,” they’ll point out.  And they’ll be completely right.

To someone casually consuming this metric, the percentage can easily mislead.  After all, 100 percent coverage sounds an awful lot like 100 percent certainty.  If you hired me to do some work on your car and I told you that I’d done my work “with 100 percent coverage,” what would you assume?  I’m guessing you’d assume that I was 100 percent certain nothing would go wrong and that I invited you to be equally certain.  Critics of the total coverage school of thought point to this misunderstanding as a reason not to pursue that level of test coverage.  But personally, I just think it’s a reason to clarify definitions.

Read More

Oct
3

By

The Different Pair Programming Styles

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

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, check out their products that help you wrangle production issues in a hurry.

The world of professional programming produces some pretty intense debates.  For example, take a look at discussions about whether and how to comment code.  We have a hard time settling such debates because studying professional programming scientifically is hard.  We can’t really ask major companies to build the same software twice, using one control group and one experimental group.  So we muddle through with lots of anecdotes and opinions and relatively scant empirical data.  Because of this conundrum, I want to talk today about pair programming styles rather than taking a stance on whether you should pair program or not.

I’ve talked previously about the benefits of pair programming from the business’s perspective.  But I concluded that post the same way that I’m introducing this one.  You can realize benefits, but you have to evaluate whether it makes sense for you or not.  To make a good evaluation, you should understand the different pair programming styles and how they work.

That’s right.  Pair programming involves more than just throwing two people together and telling them to go nuts.  Over the years, practitioners have developed techniques to employ in different situations.  Through practice and experimentation, they have improved upon and refined these techniques.

The Effect of Proficiency on Pair Programming Styles

Before looking at the actual protocols, let’s take a brief detour through the idea of varied developer skill levels.  Although we have a seemingly unique penchant for expressing our skill granularly, I’ll offer just two developer skill levels: novice and expert.  I know, I know.  But those two will keep complexity to a minimum and serve well for explaining the different pairing models.

With our two skill levels in mind, consider the three possible pairing combinations:

  • Expert-Expert
  • Expert-Novice
  • Novice-Novice

Now when I talk about expertise here, bear in mind that this accounts for context and not just general industry experience.  Tech stack, codebase familiarity, and even domain knowledge matter here.  I have two CS degrees and years of experience in several OOP languages.  But if I onboarded with your GoLang team tomorrow, you could put me safely in the novice camp until I got my bearings.

Each of these pairing models has its advantages and disadvantages.  Sometimes, however, fate may force your hand, depending on who is available.  Understanding the different pairing models will help you be effective when it does.  It also bears mentioning that novice-novice pairings offer a great deal of learning for both novices, but with risk.  Therefore, the suitability of such a pairing depends more on your appetite for risk than the pairing model.

Read More

Oct
2

By

In Defense of Using Your Users as Testers

Category: The Life of a Programmer Tags: , |

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 it for a spin; you can try it for free.

In most shops of any size, you’ll find a person that’s just a little too cynical.  I’m a little cynical myself, and we programmers tend to skew that way.  But this guy takes it one step further, often disparaging the company in ways that you think must be career-limiting.  And they probably are, but that’s his problem.

Think hard, and some man or woman you’ve worked with will come to mind.  Picture the person.  Let’s call him Cynical Chad. Now, imagine Chad saying, “Testing? That’s what our users are for!”  You’ve definitely heard someone say this at least once in your career.

This is an oh-so-clever way to imply that the company serially skimps on quality.  Maybe they’re always running behind a too-ambitious schedule.  Or perhaps they don’t like to spend the money on testing.  I’m sure Chad would be happy to regale you with tales of project manager and QA incompetence.  He’ll probably tell you about your own incompetence too, if you get a couple of beers in him.

But behind Chad’s casual maligning of your company lies a real phenomenon.  With their backs against the wall, companies will toss things into production, hope for the best, and rely on users to find defects.  If this didn’t happen with some regularity in the industry, it wouldn’t be fodder for Chad’s predictable jokes and complaints.

The Height of Unprofessionalism

Let’s now forget Chad.  He’s probably off somewhere telling everyone how clueless the VPs are, anyway.

Most of the groups that you’ll work with as a software pro would recoil in horror at a deliberate strategy of using your users as testers.  They work for months or years implementing the initial release and then subsequent features.  The company spends millions on their salaries and on the software.  So to toss it to the users and say “you find our mistakes” marks the height of unprofessionalism.  It’s sloppy.

Your pride and your organization’s professional reputation call for something else.  You build the software carefully, testing as you go.  You put it through the paces, not just with unit and acceptance tests, but with a whole suite of smoke tests, load tests, stress tests and endurance tests.  QA does exploratory testing.  And then, with all of that complete, you test it all again.

Only after all of this do you release it to the wild, hoping that defects will be rare.  The users receive a polished product of which you can be proud — not a rough draft to help you sort through.

Users as Testers Reconsidered

But before we simply accept that as the right answer and move on, let’s revisit the nature of these groups.  As I mentioned, the company spends millions of dollars building this software.  This involves hiring a team of experienced and proud professionals, among other things.  Significant time, money, and company stake go into this effort.

If you earn a living as a salaried software developer, your career will involve moving from one group like this to another.   In each of these situations, anything short of shipping a polished product smacks of failure.  And in each of these situations, you’ll encounter a Chad, accusing the company of just such a failure.

But what about other situations?  Should enlisting users as testers always mean a failure of due diligence?  Well, no, I would argue.  Sometimes it’s a perfectly sound business or life decision.

Read More

« Older Posts
Newer Posts »