DaedTech

Stories about Software

Jul
2

By

A Look at 5 NoSQL Solutions

Category: Language Agnostic Tags: , | 3 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, have a look at variety of monitoring solutions they offer to keep your production code running smoothly.

If you’ve never seen it, you should take a look at the Gartner “Hype Cycle.”  Technology changes the world quickly.  And the technology world itself changes even more quickly.  This can lead to breathless buzzword saturation, followed by the so-called “trough of disillusionment” when the tech predictably fails to cure world hunger.

Wired magazine put “Big Data” in the trough of disillusionment in 2013.  So that placed it at the peak of inflated expectations around 2011.  And, as a matter of fact, I remember that time quite well.

Everyone suddenly became interesting in something called “NoSQL.”  What was it?  What problems did it solve?  It didn’t matter — you just needed to start doing it.  And, given the year, you should start doing it in a way that somehow involved a mobile app.

What Is NoSQL?

Neither the big data movement nor NoSQL technologies have gone anywhere.  They’ve woven themselves seamlessly into the fabric of the tech world.  Only the hype has abated.

But that doesn’t mean everyone obtained perfect clarity about what this involved.  When a concept hits the peak of the hype wave, definitions get fuzzy and folks get confused.  If you don’t believe me, try to obtain universal consensus about what “agile” means.  NoSQL suffered the same fate.

You can read about some of those misconceptions here, but I’d like to focus on the one I recall as most prominent from my experience.  Specifically, many people and particularly relational database traditionalists, seemed to believe “NoSQL” was some kind of off-brand comptetitor to traditional databases.  That is, you could go with Oracle, SQL Server, or NoSQL.

I highlight that misconception to underscore the counterpoint.  I’ve seen a few different suggested meanings of the acronym, but I favor “Not Only SQL.”  Simply put, the NoSQL movement represented the idea that there were other options for storing data besides relational databases.

Read More

Jun
29

By

Freelance Programming without a Marketing Presence

Category: You Asked For It Tags: , |

Happy Friday, everyone.  I’ve had no shortage of questions about freelance programming and consulting since I started reader question Fridays.  I’ve talked about speaking to buyers and about moonlighting, among other things.  And in all of these posts, I bang the drum for building a marketing presence over the course of time.  But today’s reader question concerns freelance programming when you don’t have time to play the long game.

In that first post, I encouraged people to start building a marketing presence and brand immediately.  I invoked a saying about trees.  The best time to plant a tree is 20 years ago; the second best time is now.  In response to that, a reader asked the following.

How about making it a little quick?
I like the example of sowing the plant now and I do understand its strength but not everyone has that much time cushion in his/her life to keep doing his/her thing continuously…

Fair enough.  What do you do when you want to get going as a freelance programmer immediately, but haven’t had time to specialize or build a brand?  Well, to answer that, I’m going to take a small detour through the concepts of marketing and sales.

Marketing and Sales

Plenty of sites will tell you about the nuts and bolts difference between marketing and sales.  Generally they’ll advise you that marketing involves brand awareness while sales involves closing the deal.  And, that’s true.  But I’m going to draw a different distinction.

Simply put, marketing is “here’s a sense of the value we provide” and sales is “let’s talk about you giving me money.”  So, if you’re anything like me, personality-wise, marketing is okay, and sales is distasteful.

In fact, I’ve actually come to like marketing.  I’ve even created a business where we help tech tools and training companies with content marketing.  Basically this involves leading with value — creating content that prospective customers find interesting, but without trying to take money from them.  You attract their interest, offer them information or entertainment, and then hope that builds goodwill for the brand, eventually resulting in sales.  But you also hope that, by the time a sale becomes relevant, you’ve already given them something of value and made them an enthusiastic buyer.

“Here’s the thing we’re selling, and we think it speaks for itself — let us know if you’re interested.”

Imagine a sales process like that.  Software developers are cynical, savvy, and sales-averse, so a pitch like that is a way to our hearts (and wallets).

Software Developers as Salespeople

Ironically, in spite of our leeriness toward sales, we, as software developers are sales people.  And, we’re not even the easygoing, friendly type.  We’re the sharkskin suit, slicked back hair, high-pressure type.  We want you to hurry in for these great deals while supplies last!

Is this guy doing freelance programming or selling cleaning supplies?

Okay, I can almost see your skeptical look through the information ether of the internet.  But, seriously.  We do this when we sell our labor.  It’s called a job interview.

Read More

Jun
29

By

CodeIt.Right Rules, Explained Part 3

Category: .NET Tags: , , | 1 Comment

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, take a look at CodeIt.Right and see how you can automate checks for and enforcement of these rules.

In what has become a series of posts, I have been explaining some CodeIt.Right rules in depth.  As with the last post in the series, I’ll start off by citing two rules that I, personally, follow when it comes to static code analysis.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

It may seem as though I’m playing rhetorical games here.  After all, I could simply say, “learn the reasoning behind all suggested fixes.”  But I want to underscore the decision you face when confronted with static analysis feedback.  In all cases, you must actively choose to ignore the feedback or address it.  And for both options, you need to understand the logic behind the suggestion.

In that spirit, I’m going to offer up explanations for three more CodeIt.Right rules today.

Read More

Jun
27

By

Choosing Among Text Editors and IDEs

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

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 offerings for monitoring all of your production concerns and infrastructure.

Few subjects in programming can get as contentious as quickly as, “what should I use to edit my code?”  Before you even get to the subject of “which one,” vigorous debates emerge over “what kind?”  This cordial Quora question with roughly 6 billion answers serves as an example of this.  Text editor or Integrated Development Environment (IDE)?

Only after that perilous decision do you arrive at the “which one debate.”  So furious has this debate proved that Wikpedia has an “Editor War” entry.  It describes the choice between the Emacs and VI editors.  The usage of “war” is a joke.  But only kind of.

So against this backdrop, you might regard the choice as one fraught with peril.  Pick incorrectly and risk the scorn of your peers.  That’s a joke.  But only kind of.

Fortunately, for the purposes of guidance, at least, I count myself a pragmatist mercenary.  In other words, I come from the relatively small camp of software developers without much strong preference about any of it.  I have spent years with each of the following: Visual Studio, Eclipse, IntelliJ, Emacs, Pico, Nano, Scite, SublimeText and Notepad++.  And I’m probably forgetting some.  All have their perks and foibles, but I prefer to keep my options open and let context guide me.

So, face with the need to pick new tooling, how should you handle it?  Today, I’ll offer some advice on heuristics for selecting an IDE or text editor.

Make a Quick List of Your Needs

First things first.  Do what you would do when contemplating any sort of consumer decision.  Make a list of your needs and wants.

For instance, say you were buying a refrigerator.  You’d need a certain size to fit your space, and you’d need a certain amount of storage capacity.  You might then want a chrome finish and an ice maker.  Contemplate the tool you’ll use for writing code in this same fashion, for starters.  You may have non-negotiable needs around operating system and programming language, and more fluid wants around features.

But also bear in mind context.  For example, do you specifically need a tool to work on one specific project at the office?  Or do you want something versatile that you’ll use everywhere, across various languages and technologies?

Now, combine these two lines of thinking and you will probably have narrowed the field considerably.  And you need to narrow the field, since a surprisingly daunting number of options exist out there.  Easier to choose among 2 or 3 than from hundreds.

Read More

Jun
26

By

Computing Technical Debt with NDepend

Category: .NET 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, take a look at the newest version of NDepend and its options for helping you quantify tech debt.

For years, I have struggled to articulate technical debt to non-technical stakeholders.  This struggle says something, given that technical debt makes an excellent metaphor in and of itself.

The concept explains that you incur a price for taking quality shortcuts in the code to get done quickly.  But you don’t just pay for those shortcuts with more work later — you accrue interest.  Save yourself an hour today with some copy pasta, and you’ll eventually pay for that decisions with many hours down the road.

So I say to interested, non-technical parties, “think of these shortcuts today as decisions upon which you pay interest down the line.”  They typically squint at me a little and say, “yeah, I get it.”  But I generally don’t think they get it.  At least, not fully.

Lack of Concreteness

I think the reason for this tends to come from a lack of actual units.  As a counterexample, think of explaining an auto loan to someone.  “I’m going to loan you $30,000 to buy a car.  With sales tax and interest factored in, you’ll pay me back over a 5 year period, and you’ll pay me about $36,000 in total.”  Explained this way to a consumer, they get it.  “Oh, I see.  It’ll cost me about $6,000 if I want you to come up with that much cash on my behalf.”  They can make an informed value decision.

But that falls flat for a project manager in a codebase.  “Oh man, you don’t want us to squeeze this in by Friday.  We’ll have to do terrible, unspeakable things in the code!  We’ll create so much tech debt.”

“Uh, okay.  That sounds ominous.  What’s the cost?”

“What do you mean?  There’s tech debt!  It’ll be worse later when we fix it than if we do it correctly the first time.”

“Right, but how much worse?  How much more time?”

“Well, you can’t exactly put a number to it, but much worse!”

And so and and so forth.  I imagine that anyone reading can recall similar conversations from one end or the other (or maybe even both).  Technical debt provides a phenomenal metaphor in the abstract.  But when it comes to specifics, it tends to fizzle a bit.

Read More

« Older Posts
Newer Posts »