Friday, August 23, 2019

The dark side of git...

Git is Great!

As a distributed source code tool, git is great. I love that when I'm on an airplane I can commit code without a wireless connection and have be able to unwind what I was doing. It was clearly designed with the "offline" model in mind. The idea I can create a quick branch, experiment, make massive sweeping changes, and just drop the whole thing if I realize it sucked...is AWERSOME! For a fact this puts it ahead of it's open source predecessors (namely...SVN, CVS, and RCS).

But perhaps a victim of it's success

What I observe, however, is that a lot of folks have taken up a development model where "everything is a branch" and we end up with roles like "pull request approval engineer" (not a real title, but if you end up doing that job, you'll know that your doing it). This problem happens when the number of public branches/forks reaches a count and complexity that far exceed any value they could have possibly served.

What is productivity?

I'm going to take a somewhat unpopular stance here, but in general my stance is that branches are antiproductive... before everyone gets their pitchforks out, let me explain my version of "productivity" for a software project. Productivity is producing software that accomplishes the business purpose at a marginal cost that provides positive value. While that might have been wordy or even technically incorrect, the overall equality formula I wan to use is: sum of all activities to product the software must be less than the value the software provides. In other words, if it costs 2 million dollars to build/deploy some software, but the business can only recoup 1 million dollars in value (via cost saving or new sales or whatever) the I would consider that a failure.

The branching use case

As a software engineer, I want to create a branch so that other developers cannot see my changes in their builds.

Well that sucks because:

  1. First of all, the activity of creating the branch, merging in everyone else's branch to your branch (through possibly a different branch) is all stuff that you would get instantaneously for free if you were all working on the same mainline.
  2. Second, you're deliberately delaying visibility of changes from the rest of the team...which means the whole notion of continuous integration is getting thrown out the window
Which brings me to a key question

Are you operating with agility or fragility?

I would contend if you're branching for every feature or bug and merging them back in, your codebase and/or process is more fragile than agile.

Your Thoughts?

Saturday, January 13, 2018

The state of programming languages and frameworks

As a professional software delivery person, I like to keep on top of technology trends and "where the market might be going". Over the last decade and a half, quite a few languages and frameworks have come and gone and very few have had any real staying power. In order to be marketable and knowledgable in things that "people want to know", I generally find the Tiobe index and Google Trends to excellent resources in gauging popularity. In my analysis this year, I've established that relatively speaking, they are in agreement, so I'm going to use google trends (as the charts are easier to embed) to elaborate.

Programming Languages

Before digging into frameworks, there is the notion of "which language" is most popular? In this regard, java has been dominant and looks to remain so for a long time. While there is a downward trend, every major language has had it's mindshare diminished, I can only imagine because of the explosion of alternate languages in recent years. Assessment: learn java, become an expert because while the market is crowded, there will always be work and/or people who want to know something about it. To be clear, I disregarded C, though it does roughly correlate to C++ in popularity...it is used more in embedded markets and that's not one I'm deep into [yet].

Alternate languages

While I would recommend any newcomers pick one of the "big 5". It really helps to have a "specialized" language you are at least passingly familiar with and can be productive in. In that regard, I also tend to take the "short term" view as these tend to come an go with great regularity. In that regard, I'd say that Python (technically in the big 5 if you go by many sources) is a solid first choice, but ruby is still a viable alternative. Outside those two, almost any other modern language would be a good idea to pick up and have as there are always specialty areas that will have a need [even for legacy languages like ADA or Fortran].

Legacy Languages

One area that is often neglected are so called "legacy languages". These are languages that have fallen out of style and/or been superseded by more modern alternatives. One reason I recommend adding a member of this group to your portfolio is that many experts in these fields are retiring but the systems running on them will continue to live on. Additionally, when doing a migration from a legacy platform, being able to quickly be able to read and understand what the old platform did is a valuable skill. One area to look at is the "area under the curve" as this represents the "amount of code potentially written". In this regard, perl is a clear winner.

Frameworks

Programming languages, however are only one dimension. Beyond this, the frameworks available to deliver higher level functionality are a key factor. From that perspective, I grabbed a few notable frameworks and did a comparison (realizing node.js isn't really a framework). In this regard, ruby on rails, while declining in popularity (and surpassed by spring boot), has a HUGE installed based and would clearly be a good choice. The winner's a little unclear here, but coupled with java's popularity as a language, I think one would not go wrong with spring-boot, perhaps having ruby on rails as a backup (and it IS the dominant framework in ruby).

Conclusion

From my perspective, I have a good familiarity with java and spring-boot, plus a deep understanding of ruby on rails...so I'm still fairly well positioned and I think I could easily recommend these as "go to" choices. Beyond those, I think I may spend some time playing around with perl again as it strikes me as a market that is set to be underserved at some point in the next 5-10 years...and will be a prime candidate for "need to know to make legacy migrations go smoothly".

Friday, July 14, 2017

The Technical Estimation Paradox

Face it, we've all been there...you're asked for an "estimate" that you KNOW you're going to be held to, but there are a hundred variables you have no way to control. The client is sitting at the other end of the table tapping their fingers and you think to yourself either: #1 "they don't understand, it's unreasonable, I don't have enough information", or #2 "Hmmmm, how much do I think based on my current information it might take?".

At the end of the day, neither of those matter beyond the psychological value they have for yourself...the real question that matters is "how much is it worth to them for you to deliver this?". Yes, if you're billing time and materials, there are practical problems: If you estimate too low, your client is going to be disappointed that you couldn't deliver in the agreed to cost/time...if you estimate too high, you client might be happy, but often they also think that you cut some corners (especially if you were the "middle of the road" estimate). On the flip side, if it's a "fixed bid", if you estimate too low, your margins are going to dwindle and you could possibly lose money and if you estimate too high you may end up in an ethical dilemma where you are making 99% margin (which is arguably good or bad, depending on your perspective). But at the end of the day, as a consumer of services, you should be happy if you get the contractually agreed to qualities you care about (without assumptions) for the agreed to amount (or less), and as a service provider, you should be happy to deliver at the agreed upon price (or less) with the agreed upon qualities (or more).