Wednesday, August 25, 2010

Go Into (Technical) Debt With Eyes Wide Open!

This morning Bijan Sabet had a good blog post on being open and honest about "technical debt".

I think (and commented there) that it's important to get into such debt with your eyes open and plans for how to address it in the future.

If the context isn't clear, what's being talked about here is basically hastily put together technology that accomplishes an early version of what was needed of a product but is considered "debt" because it cannot remain in the state it is in. It is carried as a kind of liability because at some point, either because of new features that are required or it isn't scalable, time and effort will need to be *paid* in order to make it more robust.

Having gone through the process of building multiple software systems from the ground up has clarified for me how technical debt should be planned for. And nothing clarified it for me greater than working on a large project with a hefty amount of inherited technical debt that we successfully cleared off the books, and the monumental effort that it took to do so.

I find it important as you are putting a system together to consciously make the tradeoffs that are necessary and have a plan for how the code (and technology choices) would be iterated and scaled up when the needs arise.

As in monetary debt, this is akin to advising not to take a loan without having a plan for how you're going to pay it back.

Along the way there are also very smart choices you can make to help make that debt less too. Layering and using adaptors being one great example. It can be expensive to retrofit an adaptor model to something that was written assuming it would only have to interact with one particular technology. So abstracting early, even if you are in a hurry, will help you with your later "payment plan" at a fairly low cost up-front.

Another good example is having an MVC model on your UI, which will help later when you need to put an API in place (and reuse the "M" and the "C").

Something to watch out for is piling debt on top of debt (don't charge your mortgage to your credit card!). That is, when the feature comes up that needs to utilize another technology that is in need of repair, instead of making matters worse you should seriously consider at least starting to pay off the debt on the older technology.

The important bottom line is take the debt seriously and don't enter into it lightly. Yes, it's necessary, but have a plan. Things will come up you didn't expect, and you'll suddenly find liabilities where you didn't know they existed. But then you'll be freer to deal with those unexpected things since you're in better shape overall. And your future self will likely thank you for it.

Thursday, August 19, 2010

Decentralized Beats Centralized

The current uproar around Target and its political contribution that ended up supporting a Republican candidate whose beliefs many disagree with is, I think, very instructive and holds lots of lessons. (CNN info about it here.)

The biggest for me is that it shows how transparency and decentralized action can be a healthier political force in the country than centralized enforcement.

Other than an unfortunate glossing over of some important nuance (more on that below), I think this is playing out exactly as I would have hoped after the Supreme Court ruling earlier this year that corporations could make political contributions.

Even though I'm concerned with large corporations unduly influencing our government, I felt the Supreme Court ruling was correct. Previously, the regulations around what corporations could and couldn't do were too difficult to decipher. It's a difficult problem to solve by centralized fiat because there are many subjective dimensions to defining what might be allowed.

But what is important is the requirement for transparency. This puts the information out there to be dealt with in a decentalized way, which is exactly what is happening now. And, of course, there's never been a better time to make information available which could lead to decentralized forces making their voices known.

Basically the Supreme Court crowd-sourced the problem. They essentially said that instead of saying there will be a central definition of what is acceptable, we will require transparency and let the masses do the job of keeping corporations in check. And the masses, unbeholden to "Mainstream Media" and with the tools of social networks and the virality that comes with it, have never been better prepared to do this.

The good lessons for corporations here will be that they can suffer reputational harm by making political donations, even those that might seem innocuous. This should serve as a brake on their making the contributions.

In fact, this is where the lack of nuance comes in.

The reality of the money flow is that Target contributed to a pro-Business group in Minnesota called "MN Forward" (www.mnforward.com). MN Forward then contributed to the ads for the politician in question. Their issues page lists: Tax Reform, Spending Reform, and Education Reform. Noble goals all.

The bad part about this loss of nuance in the story generally is that it means that people are assuming that Target and its principals have an anti-gay agenda. An objective look suggests that they contributed to a pro-business organization, who in turn backed a pro-business candidate who also holds non-progressive social policy positions (specifically, against gay marriage).

Now, the *good* part about this loss of nuance is that it will serve as a warning to other corporations. They will realize that their motivations for making a particular contribution won't matter as they can be undone by the perceptions about a candidate that might ultimately benefit from the contribution (even if at least once removed).

Let's hope we all keep doing our job and using all of the information we can get our hands on to our advantage, and solving the problem of corporate meddling in politics by being more a part of the process that can solve it.

Tuesday, August 10, 2010

SE is to CS as ME is to Physics

The past week I have had thoughts rolling around spurred by this post by Andrew Parker. The general theme of which is "how little a computer science education matches up to the real-world building of large scale applications." I thought it brought up a really good issue.

For me the issue comes down to whether you see a CS program as vocational in nature. Back when I graduated (in '95) I thought then that the CS program at my school (WPI) was too vocational in nature.

At WPI you do a major project your senior year as part of your graduation requirement. I've always leaned to the theoretical and mathematical side, and for my Physics degree my project was in the area of Quantum Mechanical energy degeneracies in multiple dimensions. No, I don't remember the equations in detail. But it landed me a published paper in the American Journal of Physics, so that was cool.

When it came time to do the major project for my CS degree I was the only one in my class not to work on some type of coding project. Instead my project was "Complexity Analysis of the Primitive Recursive Functions." I got all the coding experience I would need being in a Coop program and then staying on to work part-time after that, writing embedded firmware code in Assembly and C and Unix (SVR4) drivers and application code in C. And I think that's the right mix.

(And yeah, I know, with degrees in those two fields you'd think I would've leaned to Quantum Computation or something, but I'm not *that* theoretically minded :-)

It seems to me the argument is around the "S" in CS being "Science". There's a real difference between "Technology" and "Science" that we should recognize.

This is obvious when you look at Physics (which I majored in) and Mechanical Engineering (which I also majored in briefly before switching that one to CS). In ME there is more a lean to technology. No technology in Physics, other than around the instruments for running experiments.

I'd argue that we need just the same type of split (with cross-over training of course) that exists in Physics and ME in the field of computation.

I think there's already been one split that's happened that makes sense, which is in the field of Electrical Engineering with a focus on computers and lower-level programming - I think I've seen this referred to as ECE.

If we then split off "Software Engineering" as a full-fledged major, that feels like: SE is to CS as ME is to Physics.

Let's be honest, there'd be a *ton* more SE than CS majors, but who cares? At WPI when I was there we probably had at least a 10:1 ratio of ME to Physics graduates. Just like ME majors have to start with some Physics courses, SE majors would have to fulfill the basic CS courses.

The upside is that the SE majors would have a clear focus and would probably come out with much stronger industry skills that would enable them to start building things right away. Again, pretty close to the analogy to ME and Physics.

I'm sure there must be places where this split of SE off of CS is already happening. If that is the case, it should just be happening even faster :-).

I was also motivated to write this by a couple mathematically-oriented CS stories that came out in the past week. The first being around the attempted P!=NP proof, which brought back memories to my complexity theory studies. For the latest on that, this blog is following it.

The other story that caught my eye was around a proof put forward that any position of the Rubik's Cube can be solved in 20 moves or less (http://www.cube20.org/).

They served as reminders to me that a CS education is much more than learning about pointers, or whether you can create anonymous classes in Java easily, or how to work with a source control system, or how to provision and manage a Hadoop cluster.

Honestly, compared to when I graduated (it wasn't *that* long ago was it?) all of that can be learned and played with online. With guides, and open source projects looking for you to contribute. And, as a friend reminded me today, things like Google's Summer of Code to really go head down into implementation.

I'm sure there's never been a better time to learn about and become a great software developer. And really I think there's more and more proof that on the "technology" side (as opposed to "science" side) it doesn't even take going to school anymore.

Tuesday, August 3, 2010

Memory Lane

Here's to the launch of the TRS-80 back on 8/3/1977 (Wired article: http://goo.gl/njnJ). I remember the model well because I had a "pre-owned" one back in the early 80's.

At the time it was an awesome upgrade from my first computer, the Timex Sinclair 1000 (although I had the 16K expansion unit for $50 for that baby!)

The funny thing about the TRS-80 is that I liked it because it looked like a "real" computer. More like what you could see in the movies. Given everything started with "War Games" for me (like everyone else at the time?) I think it makes sense.

I regret that I have didn't have an Apple computer back in the 80's. But I did follow an eclectic path from the TS/1000, to TRS-80, Coleco Adam, Leading Edge IBM clone, and then finally 386, and eventually Pentium.

At the same time my online experience started in about 1986 on a teletype we had at school with an acoustic-coupled modem dialed into a small PDP-11 network. High School brought with it a VAX cluster, college was networked Sun workstations (Gopher was all the rage!), and finally the Internet.

Some signposts I can measure my life by.