Buzz Words Killed the Radio Star

I’m ideating a method proposition to add enterprise grade value which will synergize your verticals.

*cringe* Hold on a second…I need to go wash off the dirty. In all of what I typed above, I didn’t actually tell you _anything_. But, what you expect now is some thing that should make your things work well together. Why don’t we just say that? Because people expect exact answers and the above sounds more like an exact answer! Keep in mind that most places wont do anything nearly as drastic as what I posted above.

Where To Begin?

Buzz words suck. Often times these words start as a way to differentiate products and/or services. While grande, buzz words tend to lose their meaning when _everything_ and/or _everyone_ uses them. When people adopt them on a large scale you’re not actually saying anything. Most people can get the gist of what you’re attempt to say because most people have a brain that works reasonably well, at the very least better than this weasel. However, you lose credibility when you start throwing those kinds of words around.

I’ve been, for a while now, trying to figure out why they are so popular. I’m not sure where it started. The main reasons for using them, that I can think of, are differentiation and filler.

Differentiation

The attempt to be different. This works out reasonably well when you’re the first person/company to say that you are an “enterprise” solution. But, when every competitor uses the term, SURPRISE, you’re no longer different. Or are you? What about the feature you can create a pony out of thin air? I’d say that likely differentiates you, wouldn’t you? Stick to the features and to your capabilities. Those should be what differentiates you.

Filler

If you find yourself with a lack of descriptors then use the ones you can think of. When you “innovate” in the market, what are you really doing? People thirst for information so give it to them. You don’t need to ramble on, but providing some detail is a great teaser. The movie industry uses teasers to pique your interest. You should do the same. Additionally, using buzz words doesn’t make you sound any more intelligent. In fact, it often does the opposite because you aren’t providing substance.

More Proof

If you need more proof that buzz words are everywhere and how irritating they can be. Sit at your next “all hands” type of meeting. Listen to the specific words being used. You’ll notice that a lot of these phrases aren’t really telling you much. It’s almost like eating at McDonald’s, you might get something that resembles a message, but really all your getting is an ill feeling in your stomach.

Try playing games like buzz word bingo. Another that I’ve played is to come up with a list of words and assign points to those words. Each person picks a word they think will provide the most points. Give each person a word to tally and then collect the tallies at the end. Multiply the tallies for the word by it’s value and those are the total points. Once you have the totals you send them out. The prizes are your choice, I tend to prefer a free lunch, but it at least makes the 1-2 hour snore fest more exciting. The point is that you’ll find out just how many buzz words and phrases are used to try and pitch you information and direction.

Where To Go From Here

Well, I’m certain I’ve used buzz words in the past. With so many floating around, it’s bound to happen. Fret not, you can stop using them and gain back your credibility. Make a conscious effort to stop using them and give the terms meaning again. Also, you’ll be generating more intelligent conversation. This, to me, seems like a positive.

Suggestions

You may be able to get a clearer picture of exactly what I’m talking about with some examples. So, here are some off the top of my head.

• Enterprise – We can handle a lot of [users|documents|<insert noun>]. When you say this you’ll need some statistics. So have them ready.
• Web 2.0 – Our web application is primarily built using Javascript, AJAX, and some aesthetically please designs. We are also standards compliant.
• Synergy – Our product works well with <insert other technology>. Or, this will allow <X> to work well with <Y>.
• Best of breed – We’ve used <X> technology. This gives us the ability to do <Y>.
• Leaders in – Hmm… No you aren’t. Just accept it now and get over this phrase. KTHXBI.

Authenticity

One thing I touched on above was authenticity. When you stop using gibberish in your messages you gain credibility. People start to listen to your messages because they are gaining something from it. If you are interested in some ways to approach this take a look at Personality Not Included. I read this some time ago and really liked much of what Rohit had to say.

Go Forth

Go now and conquer! Take out those editors, rewrite those presentations, press releases and websites. Get the word out that you wont put up with buzz words anymore. And, if someone tries to push you into it, you can always threaten them.

Apache Modules, SEOversite and Debugging C

At Axiom Software we’re working on the next release of SEOversite. It’s been exciting. This is basically a tutorial on debugging the Apache HTTPd side of things (keep in mind that this is as much an informational thing for you as it is a reminder for me. I assume that I’m going to have to re-read this at some point).

Background

In production, we’ve been using Apache on Ubuntu Server. This has worked out well seeing as aptitude rocks pretty hard. But, we run into some issues doing debugging and profiling. It’s easier to have the code all within one place, so for development purposes we’re pulling the source so that we can specify the configuration and compiler options for Apache.

Debugging

What other tool do you use to debug C code than the GDB? With any language you need a way to be able to properly debug your code and usually print statements just don’t get it done. So, why stop at the ability to print out from the code when you can actually step into your functions, print out variables, and see back traces. With normal C applications you can simply just load the binaries into GDB:
# gdb <binary>

This doesn’t quite work in our setup though. We are in the situation where we need to debug modules, not just Apache. And, to really be able to step into the code we need to compile it appropriately. When we’re dealing with setting up our module for debugging we need to make sure we pass in the -g flag. The -g flag just makes it so that your code can be debugged with gdb.

So, we have our module which we’ll call seoversite.c. We’re looking to debug so our build looks something like this:
~/seoversite/# /opt/apache/bin/apxs -ci -Wc,-g seoversite.c

This turns on debugging within the binary which means that we are letting GDB process the source of our file. With apxs, the -Wc, flag allows you to pass compiler flags along for when your code is actually built.

We then have a really simple startup for GDB.
/opt/apache/# gdb bin/httpd

As soon as this fires we get a prompt that lets us specify what we want to do. Today I was debugging a simple method that processes a URL so I’ll go through some of that. When we start up gdb we’re presented with a prompt. This is where we need to enter some input.
(gdb) b get_fullurl
Function "get_fullurl" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (get_fullurl) pending.

Because our module is shared, gdb doesn’t find the method signatures right away. That’s ok. We’ll wait till they load on the request. Basically, the above puts a breakpoint on the method call get_fullurl. Thus, any code paths that use get_fullurl will halt activity until processed in gdb. So, we start the server.
(gdb) run -X
Starting program: /opt/apache/bin/httpd -X
[Thread debugging using libthread_db enabled]
[New Thread 0x7fce2930d760 (LWP 14174)]
warning: Temporarily disabling breakpoints for unloaded shared library "/opt/apache/modules/seoversite.so"
[Switching to Thread 0x7fce2930d760 (LWP 14174)]

The command we typed was “run -X” meaning, start the binary with these command line options. -X is the debugging flag for Apache. So, we’re telling it to start Apache HTTPd in debug mode. This is what we want. It tells you that it’d loading a shared library and is going to disable the breakpoints while it loads. Afterward it enables the breakpoints you’ve defined. At this point, because our code is dependent on a request, we should make one. I hit a virtual host url that is setup to use our module and immediately see that our method is hit.
Breakpoint 1, get_fullurl (ctx=0x19d4908, use_base=0, args=1) at seoversite.c:330
330 if (use_base) {

This isn’t entirely useful information. I know where my method starts. However, we aren’t limited to just this information. Let’s say that I want to see the back trace of method calls that got me to this method.
(gdb) bt
#0 get_fullurl (ctx=0x19d4908, use_base=0, args=1) at seoversite.c:330
#1 0x00007fce2402299a in filtering (f=0x19cba78, bb=0x19d0298) at seoversite.c:1739
#2 0x000000000044f446 in ap_pass_brigade ()
#3 0x000000000047b2ed in ap_proxy_http_process_response ()
#4 0x000000000047bad0 in proxy_http_handler ()
#5 0x000000000046af37 in proxy_run_scheme_handler ()
#6 0x0000000000467524 in proxy_handler ()
#7 0x0000000000441450 in ap_run_handler ()
#8 0x0000000000441ce9 in ap_invoke_handler ()
#9 0x000000000048823c in ap_process_request ()
#10 0x00000000004851f0 in ap_process_http_connection ()
#11 0x000000000044ae72 in ap_run_process_connection ()
#12 0x000000000044b2f9 in ap_process_connection ()
#13 0x00000000004ac48b in child_main ()
#14 0x00000000004ac56e in make_child ()
#15 0x00000000004acb03 in ap_mpm_run ()
#16 0x000000000042857c in main ()

This is now getting useful. Not only is this nice for debugging purposes, it’s really nice for inspecting call traces of modules you’ve never used before. Inspecting the actual behavior will provide you a much better clarity of the source code. In our case, this confirmed my assumption of the calls that lead up to getting to get_fullurl.

Now I know how we got to my method, but I need to see where it’s failing. Ideally I have the source up in Emacs and can look at line numbers while debugging. What I don’t get with this however is the ability to go one line at a time and inspect the values and types of variables. GDB provides this capability.
(gdb) n
334 if (ctx->f->r->parsed_uri.query != NULL && args) {

As with most debugging software, this allows me to step through code, line by line, to see what the execution does. Obviously, this is a useful thing. But, to enhance it we get the ability to inspect variables.
(gdb) n
334 if (ctx->f->r->parsed_uri.query != NULL && args) {
(gdb) p args
$2 = 1
(gdb) p ctx->f->r->parsed_uri.query
$3 = 0x0

And, to make sure you have the appropriate context for what you are dealing with, you can print out a handful of lines to accompany your inspection.
(gdb) l
327 char* baseuri;
328 char* fullurl;
329
330 if (use_base) {
331 baseuri = get_baseuri(ctx->f->r);
332 } else {
333 if (ctx->f->r->parsed_uri.query != NULL && args) {

Ultimately this has made things easier. And, there is no longer the “ok, add a new print line in here, recompile, run, check logs, rinse and repeat” type of process. It really simplifies my life when I have to hack on C code and I know it helped one of our other guys track down some memory based issues. The only downside here is that there is no longer any sword fighting.

Adapting To Change

Homework

If you watch the following video with Trent Reznor, it’s about 40 minutes long, you’ll likely understand the rest of this post. But, for the TL;DL crowd, the interview had a lot of undertones to it that I really thought needed to be elaborated on. Not only do they pertain to what he’s doing within the music industry; what he discusses has to do with, at the very least, the tech industry. I see it as a fundamental shift in the way business is being conducted. At any rate, take a glance, and there will be more after the video.

Thoughts

First- Trent Reznor is the f*ing man.

Second- Trent Reznor is the f*ing man.

Third- there is new information coming out lately about how we’re in a time of mergers and acquisitions (M&A). M&A is a way to grow your company in size (employment), in revenue and, if you did your homework correctly, in profit. Ultimately the point of the larger companies is to make themselves money. They need to sustain the business styles they have grown into. Younger companies tend to be far less concerned about the profit engine as they are a bout their idea. Pay attention here. If you listened to what Trent said about record labels and artists then this should sound familiar. However, his thoughts don’t just apply to the recording industry.

Small businesses tend to be focused on producing some idea that changes the world, makes it a better place to live in, or makes my cheese burger taste even that much better. They are _not_ focused on whether the special sauce will be cheaper if they use Angus vs norm. In fact, a lot of smaller companies will make a deliberate decision to go for quality. They know it will cost more, but often that deliberate decision is an important differentiator in the market.

However, the businesses doing M&A tend to be focused on things that generate profit. They need to feed the meat grinder and produce dollars. After all, they have investors to satisfy. But, and this is where Trend hits the nail on the head, if you want to keep your vision, in most cases, you need to stay away from the M&A scene. If you’re looking to just make some cash or want a much larger exposure to the market knowing that you may lose some of that “somethin’, somethin’” then M&A may be right for you.

Something to keep in mind here is that the internet does allow for a great “grassroots” style exposure method. While the phrase it overused and overassumed, “your stuff could go viral!!! OMG!”

Fourth- in the interview Trent provides some notes about what artists starting out can and should do. This is not unlike the technology industry. Now-a-days there is often very little capital required to start. You can literally buy a domain and hosting for 21 dollars a month, throw up a blog, software, etc. and you’re on your way. The most expensive equity at that point becomes sweat equity. Here is something to note, investors tend to like it if you require less money from them and can produce something which will make them rich. Seems to make sense yea? If you can show that you work your ass off, made this product in your “free” time, and then have plans for the future, you’re well on your way to getting some funding.

Keep in mind that getting funded is much like acquisition. While the investor will be much more likely to care about your vision they are still concerned about the profit engine. However, because it doesn’t feed into some conglomerate view of the bottom line, there is a bit more attention on the details that make your company tick.

Fifth- things are changing. The way that business is done is changing. This is somewhat hidden in my fourth note. Trent noted a distinct difference with the way artists need to operate now from when he was coming into the industry with Nine Inch Nails. The technology that exists today makes it so that the companies today that are really taking off are just starting as hobbies or side projects. There are a ton more as well. The point here is that these companies are utilizing the infrastructure to make something really interesting and really useful, but most importantly, something that they themselves want to use. This is where I see technology companies going.

There are a few things about this topic I haven’t elaborated on. If you make something that you yourself want to use then you will likely lack passion, devotion, and when the chips are down it’ll be easier to cashout than to dive back on in. Starting projects, companies, or ideas is hard work. It requires a ton of time and effort. You’ll get to a point where it will feel better to just throw it away. But, if what you are doing is worth it to _you_ then you will pour that extra cut of “oomf” and push through it. And, IMO, if investors overlook this crucial element, they don’t deserve the profit you would make them.

Video Editing Software for Linux: Kdenlive

Linux has some great software built for it and the video editing arena is no different. The videos that I create tend to be fraps based out of games, but they still require some editing. I was interested in finding some software that wasn’t hard to use and would allow me to produce quality videos.

Enter Kdenlive. Kdenlive is a non-linear video editing tool that provides nearly everything that an amateur like me would want. And, having seen Adobe Premiere Pro, I’d imagine it’s what professionals want as well.

The software itself is laid out really well. My focus and attention is always on the video itself. And, since the second area where I do most of my detail work is with the tracks, it only makes sense that it be very large as well. The project tree, left of the video, can be toggled for other things as well. You can view the effects and the transitions lists in this pane. Then, should you want to add something you can drag it in place.

I have checked out some other software before too but it was incredibly buggy and way too crashtastic. The one I tried the most to use was OpenShotVideo and it just isn’t there yet. It seems like it could be a great tool in the future. For now, this novice is sticking with Kdenlive.

At any rate, I’m not great at “reviewing” video software since I do so little of it. I just wanted to throw out a post mentioning the capabilities here in case others of you who do the same thing I do with video were interested in it. I hope that this is helpful to someone.

Fixing Mistakes – Some Thoughts On TDD/Rot/Debt

Software development is always a good way to realize that you’re human. I’m sure there are other professions that give you this feeling as well, but my experience is limited to the software development field so I’ll talk about it from that light. There are really two ways to go on this subject. I could talk about code rot and the need to clean it up and/or talk about test driven development. Because I think they both have something to do with each other, why not make it about both eh?

The Church of TDD

Test Driven Development is a nice concept. The key here is concept. The idea here is that you write tests for a piece of functionality (ideally you know what you’re trying to get out of your function) and then write the actual functionality such that all your tests pass when your functionality is complete. Why you might ask? Well, I’ll answer! The reasoning is that when you’re 3 months into your project, breaking Brooks’ law, and trying to cope with the ever changing requirements of your project, you’ll simply have to make your change and re-run your tests. If they fail, you caught the problems at test time rather than at 3 AM when your boss friend calls you up and lets you know that he was just informed about emails being sent around to customers with usernames, email addresses, phone numbers, and contact lists for about 500,000 users.

Obviously a made-up case, but I have read about similar scenarios. That said, test driven development is only useful when you’re testing the right things. Testing functionality isn’t just about testing that you get a string back in all cases. Let’s say your working with Java and StringTokenizer’s. You might need to test the return values of each token. Also you may have to test the number of tokens or if a token is supposed to be empty that it isn’t null. If an exception should be thrown, you should check that case too. There are plenty of example cases to check here, but the point is that if you’re testing a method and only checking that something was returned then you aren’t finished.

Start out with a plan. This works in either the agile or waterfall methodologies. By this I mean, think about what you are about to produce. It usually helps me to take a step back and process what the method is expected to do. “What do I expect to see when I call x()?” “What assumptions do I seem to be making about x() where I’m calling it?” Running through questions like these are a good way to get a base set of tests for your functions.

So now you have a handful of tests that should make sure your code works right? Right!?!? Not necessarily. Let’s go back to my first line here. “Software development is always a good way to realize that you’re human.” You’ll miss something. It’s inevitable and, what’s better, it isn’t because you are bad at what you do. There are so many other things that are likely going on in your brain. If you are anything like me the whistle of a dart flying by your head or the ping and the pong of a game going on in the distance is enough to bring you out from your “I should write tests” concentration. What’s more, there are just going to be cases that you miss. It is O.K. to miss things, but there is a stipulation here. When you do and when it is caught, you need to write a test that checks for the situation/case.

Subscribing to TDD for the sake of it wont get you far and will likely slow your productivity. But, if you take a pragmatic approach to TDD and write tests as you think of cases your source base will likely be more stable since you’ll find bugs when you run the tests instead of through the client. And, you’ll have a system in place for those bugs that do slip through so that you can make sure they don’t come up again. Clients are a lot less understanding when you have issues with your code base and you can’t assure them that you wont ever have that problem again because you have no tests in place to ensure it.

Code Rot and Technical Debt

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. – Ward Cunningham on Technical Debt

Software development is one of those knowledge based fields. You write software with what you know at the time. If you are any good at what you do, you should still be learning every single day. The old saying “you can’t teach an old dog new tricks” really doesn’t hold water in this industry. Once you stop learning new things, techniques, and methods, you’ve effectively signed yourself into retirement or unemployment. That is just the way our industry works.

So, with this new-found knowledge and all powerful ability you’ll begin to smell something. It’s a familiar smell. You’ll be working on your code base and look at a method you wrote a couple weeks ago and have to plug your nose. That, my friends, is code rot.

The two, technical debt and code rot, are interesting. Understanding that you may take shortcuts to get a project moving only works when you refactor. If you do not refactor your code after you’ve introduced the questionable code you’re in for a “fun” time.

Lets not get the two confused. Code rot is typically when things change external to the code such as your ability to program or changes in the industry that your software works with. Technical debt tends to be what you introduce knowingly to the code with the intention of cleaning up later. However, as you find code rot, it becomes technical debt when you do nothing about it.

Technical debt is something that needs to be paid back. Relating this to real life; imagine yourself going so far into debt that you cannot imagine yourself ever getting out from under the load you carry. You will either be stuck with extreme payments the rest of your life or you’ll claim bankruptcy. In a software project, the equivalent of bankruptcy is a complete rewrite. You have invested time, sweat, tears, and likely a decent amount of money into whatever you’re working on. You don’t want to lose what you already have, but sometimes it’s inevitable.

The point I’m trying to make here is that you need to be willing to pay back your technical debt such that when you incur more debt, you aren’t overwhelmed by it. Paying that back can be related back to time and effort. Hell, even if you spend 5-10% of your time just refactoring your code you’ll have been paying back some of the incurred debt.

I’m probably beating a dead horse here so I’ll move on.

Problems

There are always issues right? “Sure, what you’re saying makes sense, but we don’t have the time or the budget to go through our code and fix it.” I know. I’ve heard and said this before. But, think about it like this.

I have a car. I drive it places and it serves me well. I put gas in and all is right in the world. Then one day I feel some light vibrations when I press the brake. I don’t think much of it because the car still _works_. I don’t have the time to get it taken in to the shop. About a week or two later I feel a stronger vibration and every so often some squeaking coming from the car. Again, no time- I’m a busy man! Another couple weeks pass and now the squeaking is a screeching and it’s loud. It pierces my ears. I know that sound and realize that it means I likely need to fix more of the car. Now things are getting pricey and I don’t have the money to fix it all at this point.

You see what’s happening? I put it off so long that it became prohibitively expensive to surgically remove the rot. Instead now it is going to cost me a fair amount of cash, time, and effort to actually get these fixed. And, who knows, if I continue on the current path I might end up in a wreck.

Still when you are under constraints that you have very little control over there doesn’t seem to be much that you can do. Most of the time you are forced into situations where you either piss off the PM’s and management or just continue to let the code grow it’s warts. Ideally, you’ll prove to those that make time and budget based decisions that your changes will be worth it. By worth it I don’t mean “the code will be better”, I mean “in the long run, we’ll say 30% and gain 5% in revenue”.

Solutions

One of the serious mistakes that developers make with manager types is that they think they are relating to them with terminology and analogies. Typically it requires actual impact to prove that you are right. In order to get impact values you have to gather some metrics. Hopefully some of what follows can help there.

If you already have tests in place for the code you’ve written you can do a couple of things. Lie to the people that are asking you what you’re working on. *cough* working on that scalable synergistic thing-a-ma-bob that will grow our profits exponentially *cough*. Or, you can tell them the truth. Regardless of what you do, you can have some faith in the fact that your system should operate in the way you expect it to because you have tests in place for just this reason. At some point this code was going to be changed and you wanted to make sure that you did some CYA when it did change.

If you don’t have tests you can again, lie to the people. Or, you can explain to them why it is important and some tactical approaches to solving the problems. Some fuel for the fire:

• Measure and Frequently Repay Technical Debt – Intel Software Network Blogs
• Start Paying Your Technical Debt – The Mikado Method – Thoughts of a Goldfish
• The IT Manager’s Dilemma with Software Debt – Chris Sterling’s Blog

Think about things like this. You want to get rid of this technical debt. It’s very likely that the project manager does too. But, explaining these things to the people who are interested in release dates can be challenging. Try explaining that customers are more happy when their software works. The more you can ensure that the better. Often it’ll require charts and figures with bug numbers over time. Be sure to show where you’re making improvements too. For instance, “as you can see we refactored the code on 3/12 and the number of bugs being reported decreased by n%”. By doing this, you are effectively showing ROI and how your changes  affect the bottom line. For people concerned mostly about money that is important.

And, if all else fails, show them this video!

Sometimes it’s better to just ask for forgiveness in doing these things. Even if it means temporary irritation, the benefits  outweigh the downside.