If you’re a software developer, there’s a decent chance you’ve been embroiled in the debate over integrated development environments (IDEs) versus text editors. Users of IDEs will tell you that they facilitate productivity to a degree that makes them indispensable, whereas users of text editors will tell you that the IDEs are too big and bloated, and hide too much of the truth of what’s happening from you. In some cases, depending on the tech stack and personalities involved, this can become a pretty serious debate.
I have no intention whatsoever of wading into the middle of that debate here today. Rather, I’d like to tackle this subject from a slightly different angle. Let’s take at face value that text editors are comparably feature-poor but nimble, and that IDEs are comparably feature-rich but laden with abstraction. Framed as a tradeoff, then, it becomes clear that realizing the benefits of one choice is critical for justifying it. To put it more concretely, if you’re going to incur the overhead of an IDE, then it had better be doing you some good.
With this in mind, what should you expect from an IDE? What should it do in order to justify its existence, and what should be a deal breaker if missing? Let’s take a look at what’s reasonable to expect from IDEs.
This week, I’m making it two in a row with a reader question. Today’s question is about an internal company framework and how to survive it. Well, it’s actually about how to work effectively with it, but the options there are sort of limited to “get in there and fix it yourself” and “other” when the first option is not valid (which it often is not).
How does one work effectively with a medium to large sized company-internal framework? The framework has one or two killer features, but overall is poorly abstracted and [released] with little QA.
I think the best way for me to tackle this question is first to complain a little about Comcast, my erstwhile cable company, and then come around to the point. They recently explained, in response to one of my occasional Comcast rage-tweets, “[The] promotional pricing is intended to offer you the services at a reduced rate, in the hopes that you enjoy them enough to keep them.”
@daedtech promotional pricing is intended to offer you the services at a reduced rate, in hopes that you enjoy them enough to keep them when
This is, in a nutshell, the Comcast business model — it was an honest, and forthright tweet (unlike the nature of the business model itself). What Comcast does is reminiscent of what grocery stores do when they flood the local shopping magazines with coupons: differential pricing. Differential pricing is a tactic where in you charge different rates for the same product to different customers, generally on the basis of charging more when people are non-price averse.
The trouble is that outright differential pricing is usually illegal, so companies have to get creative. With the grocery store, you can pay full price if you’re generally too busy for coupons, but if you load up with serious couponing, you can get that same grocery trip for half the price or less. They can’t say, “you look rich so that’ll be $10.00 instead of $5.00” but they can make the thing $10.00 and serially discount it to $5.00 for people willing to jump through hoops.
Comcast does this same thing, but in a sneakier way. They advertise “promotions” and “bundles” to such an extent that these appear to be the normal prices for things, which encourages people to sign up. Then, after some time you’ll never keep track of and never be reminded of, the “regular” price kicks in. For me, recently, this turned out to be the comical price of $139 per month for 24 Mbps of internet.
When you call them to ask why your most recent bill was for $10,928 instead of $59.99, they’ll say “oh noes, too bad, it looks like your bundle expired!” And this is where things take a turn for the farcical. You can ask them for another bundle, and they’ll offer to knock your monthly bill down to $10,925. If you want to secure the real savings, you have to pretend for a while to be canceling your service, get transferred over to the “retentions department,” and then and only then will you be offered to have your service returned to a price that isn’t absolutely insane. I suspect that Comcast makes a lot of hey on the month or two that you get billed before you call up and do that again, because the ‘normal’ prices are equal parts prohibitive and laughable.
Why am I mentioning all this? Well, it’s because when the time came for my most recent annual Comcast gouge ‘n’ threaten, things got a little philosophical. I wound up on the phone with an agent to whom I confessed I was sick of this stupid charade. Instead of arguing with me, he said something along the lines of, “yeah, it’s pretty ridiculous. Before I started working here, I used to hate calling up and threatening them every year, but the thing is, all of the other companies do it too.” This was either a guy being refreshingly honest, or a really shrewd customer service tactic or, perhaps, both.
But the interesting message came through loud and clear. In my area, if you want TV and internet, it’s Comcast or it’s AT&T. And if both of them behave this way, it goes to show you the power of a monopoly (or a nominally competing cartel). Their motto is, in essence, “Comcast: it’s not like you have a choice.”
Today, I’m going to answer a reader question that asks for my opinion on a blog post from medium. In it, the other talks about what he calls “maintainable code,” but what I actually think of as “common code.” Before I get started talking about these terms and the difference, however, consider the actual reader question.
It would probably help to read both pieces for background, but in case you don’t have the time, I’ll summarize the train of thought here. In my post, the one to which the reader refers, I talk about the (small) intersection aesthetic appeal and software writing. In the medium piece, the author, “Mr Galute,” draws a distinction between “brilliant code” and “maintainable code.” Brilliant code, more or less, is the sort of code that requires a unique mind to dream up and a unique mind to understand, while maintainable code is the sort that any pro developer can maintain. The overlap here is an interesting one, to be sure — this supposedly ‘brilliant’ code would seem to offer a specific kind aesthetic appeal in the same vein as solving a math problem in an unprecedented, but needlessly complex way.
As for what I think of the post itself, I’m skeptical as to the existence of this ‘brilliant’ code, and I suspect the author is a bit too. He makes a point that I really like in the first part of the post, and then, unfortunately, in my estimation, follows it up with something of a non sequitur in the form of examples of what he considers to be “maintainable.” Here’s my quick summary of his post, if you don’t want to read it in its entirety.
I worked with a guy that was (or seemed) really smart. He wrote crazy complex code and acquitted himself well in justifying it, so we assumed it was necessary. This brilliant coder was also something of a bully, intimidating and chasing off anyone who dared question his special, unique approach.
But then he left, and we’re kind of screwed. Nobody really understands what he did, which means that we either need to maintain code that we don’t get or else that we need to rewrite it. Management learned its lesson from this, and realized that it’s better to have boring code that the group understands, rather than ingenious code that only one person understands.
I am absolutely with “Mr. Galute” up to this point, and I would probably even take a stronger position. I’d argue that his difficult but ‘brilliant’ former colleague wasn’t actually particularly brilliant. It takes a lot of cleverness to write code that both contains complex, unique approaches and that your colleagues can understand. It doesn’t take as much cleverness simply to write code that no one understands and then to bluster a lot about it. That’s the stuff of which expert beginners are made.
But then Mr. Galute goes on to explain what it means to write maintainable code. This is something he calls “the 10 commandments of maintainable code in C” (though he argues that they are applicable to C# as well), and they round out the post.
Thou shalt comment thy code.
Thou shalt use white space.
Thou shalt use meaningful variable names.
Thou shalt use indentation.
Thou shalt not squeeze all thy expressions into one line.
Thou shalt include all the headers thy code needs.
Thou shalt be explicit in they requests of the compiler.
Thou shalt use methods and functions to break up thy code.
Thou shalt use braces for thy loops and conditionals.
Thou shalt use parentheses to control operator precedence.
After being completely with him up to this point, I found myself scratching my head as I read these. Maintainability is the property of code that lets maintenance programmers make changes relatively quickly and with low risk. Is that really what’s being described here?
Don’t look now, but I’m pretty sure this makes three weeks in a row of doing at least 1 reader question per week. Today, I’m going to tackle a question I received: is programming art? Here is the actual text of the question. It’s a well-written consideration that cites two parallels: painting and writing.
This article asks if computer [scientists] apply scientific methods, but perhaps we should reconsider the premise, is computer science even a science at all? I contend that a software engineer has more in common with an artist than a physicist. If a painter applied scientific principals and determined that the most pleasing color is purple and the most pleasing subject matter is a tulip, then all artists would paint nothing but purple tulips, which would not be pleasing at all.
Lets compare the developer to another type of artist, the writer. Whether you’re writing the great American novel or assembly instructions for a book shelf, or anything in between, you must consider questions like what tone of voice should I use, how formal should it be, how long should each chapter be, etc. There is never a single, scientific answer to those questions any more that there is to questions like how long should a method be, how descriptive does a local variable name need to be, etc.
To answer these questions, any writer or developer must consider the target audience. The great American novel will be written in a much different tone than a book to teach children how to read. The audience for your code is not the user (that’s the audience for the UI). The audience is the CPU, but much more so, its the next developer who needs to edit your code, or even a future you.
Bear in mind that this was written against the backdrop of this post that I wrote back in the fall, in which I answered a reader question about whether what programmers do is scientific (as in the “computer science” that we learn). Thus the sentiment here seems to be, “I think maybe what we do is better compared to art than experimental science.”
What Is Art?
But before going further, I’d like to level set a bit with the actual definition of art. If I go the classic, find a dictionary definition route, I get an adorably Lieutenant Data-like answer.
1. the quality, production, expression, or realm, according to aesthetic principles, of what is beautiful, appealing, or of more than ordinary significance.
2. the class of objects subject to aesthetic criteria; works of art collectively, as paintings, sculptures, or drawings: a museum of art;
an art collection.
If I go look for any numberof essayson the topic, two main themes emerge. The first is some rallying around the “it’s hard to define, but maybe it’s like the obscenity case in that I know it when I see it.” I think this line of reasoning is intended as inoculation against the philistine in the art museum saying, “throwing paint at a canvas ain’t art — I coulda done that!” That one isn’t particularly interesting for our purposes here, which brings me to the second theme: aesthetics.
Editorial Note: this post was originally written for the SmartBear blog. You can read the original here, on their site. As I’ve mentioned before, they have some good authors that I respect writing over there, so give it a look!
I’ve made stops in a lot of software development shops in my career, both as an employee and as a consultant. This has afforded me to the opportunity to learn that some questions and concerns are universal in the industry. One such question, asked by Fortune 500 CTOs and tiny startups alike, is “How do I make sure we have good code?” If that seems like it’d be hard to answer, rest assured that it definitely is. As much collective practice as the world has writing software, we’ve not managed to agree on the answer to a deceptively difficult question: what is good code?
David Starr wrote about this topic some time back in an excellent article entitled “Defining Code Quality.” It’s hard to opine about how a software group can have and maintain superior code quality when, as David points out, it’s difficult even to reach consensus on what it means to have superior code quality. So let’s talk about that first.