Explaining tech debt to non-technical people

Its best to start with the reason why anyone gets into debt, in the first place

People get into financial debt because some things are really expensive, and you just can’t wait.  For instance, nobody waits until they’ve saved up enough money to pay cash (full amount) for their first house. No way! You borrow money and gradually pay it off. Software development is often like this. What it costs is time & money. Money can be borrowed but can you borrow time? Yes. For software development, you can borrow from “technical purity” (aka “quality”).

When you borrow from a bank, they won’t lend you more money than you can afford. “How big of a house payment do you think you can you handle?” If you go too big, you will struggle to make the payments (and still eat food). This is why folks compromise a lot on features. You can always do some upgrades someday, when you can afford it.

Big software projects also cost a lot and have lots of (nice) features. You start by defining what you need and what you want. Then you build a schedule around it and start picking deadlines and intermediate checkpoints. Typically, this is when reality sets-in and you get sticker-shock. Some of the shock is commonly relieved by extraordinary levels of optimism (ehem), and adjusting the timeline to something more-affordable. Realism seems to be very negotiable at this point, and it creates risk before you’ve even started.

Things Get Real

Once the real work starts, reality starts too. Optimism gradually gets converted to realism. The timeline starts stretching and you face some tough choices. Time to reconsider your choices and make some trade-offs. You can drop or delay some features, or maybe accept lower quality. This is called “Do you want it right, or do you want it right-now?” Every team will start with big dreams of perfection, but get-real when the timeline slips enough.

Or do they?  You can see where I’m going with this, right? My wife will easily testify that I can’t see dirt/messes that she cannot ignore. A little dirt on the floor doesn’t bother me. It is probably something similar for bargain construction or crunched software development. Some flaws are less obvious, and for some people, this can be easy to overlook and live-with. This is one way to get more done for less.  But still, YGWYPF.
…and that is tech debt.

Why you keep tech debt

It makes sense: management cannot actually “see” most technical debt. It is strictly a problem for developers and support staff, and no-one else. Nobody else can see (or appreciate it) because they simply do not have a vantage-point from-which to observe stuff like that. They are usually not aware of how software development works. Therefore the concept of technical debt can sound like a boogey-man which only exists in your imagination. Some managers even think it is just a smoke-screen or boondoggle.

What is the concern? Well, if your team only works on new features, and never cleans-up tech debt, then it feels nice when everyone sees new features all of the time and is impressed. However, if you don’t resolve technical debt, it will progressively take longer to implement new features. It consistently subtracts productive time from your schedule. You could be getting “more done” if you resolve some of the technical debt. It can be a difficult concept to convey, but it is a proven fact. Steven Covey even talks about this as 7th habit of highly-effective people.

For software, the interest is paid in support hours.  The more tech-debt, the longer it takes you to find,  understand (how does this work in-the-first-place), fix (and test) problems, and complete updates and improvements. Source-code seems so abstract to most people, that it is difficult to imagine the difference between simpler/better abstractions or the opposite. It is easier to imagine software designs as “one man’s treasure…” 😉

Bottom line: as long as you have the debt, you will pay interest, which reduces your ability to pay-down debt, and buy other stuff.  Less debt = less interest = more cash & buying-power. For software development & support, this translates into: Less tech debt = less time wasted trying to figure-out stuff without breaking other stuff = more gets-done-quicker.

Keep your head above water.  Live within your (technical) means.  Pay down technical debt regularly & consistently. Always keep far-away from technical bankruptcy.

Outsourcing responsibility

Progressive (insurance company) is pretty proud to tout that they are primarily a software development corp, who happens to also do insurance.  They believe this is why their business is so successful. To them, software development isn’t some hassle they have to deal-with sometimes. No, it is front & center to their business and their primary focus. They embrace it and commit to doing it well.

There are plenty of organizations who rely on in-house custom software but will tell you they have no intention of going overboard like Progressive insurance.  Being good at software development is pretty hard, and if you believe software dev isn’t core to your business, you might believe that you don’t need to become good at it.  Maybe you could rent/contract some folks who are good at software development, and they could take care of that for you.  They could write a cool program for you, and then leave. You never have to think about it again. Easy-peasy.

It makes sense, right?  Like if I want a building: I don’t attempt to master the craft of carpentry, or add a construction department to my company, right? I pay a company to make me a building. They build it. Done.  Same for a car, or computer.  Even accounting: I don’t need to learn accounting or law. I should just be able to rent an expert when I need one, and then be done with it.

Outsourcing

Unfortunately, with software development, it is not-quite that simple sometimes.  The problem stems from the fact that software development is still a relatively new industry.  Like medicine, people don’t know it all yet.  There are some laws around IT and intellectual property, but most of the time, software development is not well-regulated (etc), so the quality & outcome can vary greatly.  If a (completed) software project is delivered in good shape and quality, woo-hoo! Everyone is happy.  If you get a bad one, what recourse do you have?  It is hard to say sometimes.

Some people believe that if you outsource your programming to a big-enough company (big IT staffing firm names omitted) maybe that business has some skin (reputation) and if things go bad, you can get a piece.

Responsibility / Loyalty

One of the biggest problems from renting programmers stems-from the fact that you cannot effectively outsource responsibility. It doesn’t work. Ultimately it is a byproduct of (the makeup of) the laborers and the volatility of the workplace.

Consider this: imagine I am a programmer employed by XYZ consulting, and contracted to your company. I’m a responsible guy and I do good work. Every day, I do some work for your company and try to provide a good value.
When I do, what is my reward?
Each week, I get paid by my employer. I get to keep my job, and get paid. That is all (pretty much). Of course, I may get some kind complements from my customer, and that is nice, but bottom-line: I get one paycheck per pay-period.

What do you think is going to happen if (for some reason) my employer and my customer have a difference of opinion? Whom do I obey? Ethically, I would never want to do a disservice to my customer. However, they don’t really pay me. My employer does. It sounds bad to say it, but the money (under this model) is the same, whether I do a great job or a so-so job. It is a contract. The customer also cannot give me a bonus or a raise. They have to give it to my employer, and my employer decides how much of it (if any) goes to me. Of course, when I do a great job, it is likely to have long-term benefits, but not much short-term benefits.

One other incentive to consider: when my project is done, I’m done too. The only part of my hard work that is going to stick with me is (maybe) reputation. The tangible benefit will stick with my customer. They receive long-term utility from my work. I only keep my pay. If I want to get another paycheck, I need a new project. Hopefully my employer cares about me and they find something for me to do. Hopefully, my hard work & reputation-building has made that easier. However, it still depends on 1) Will my employer try hard enough to find more work for me? 2) Are my skills currently marketable? Are there any companies who need my skills and are those companies willing to pay my employer’s rate for my skills?

…but I digress. Bottom line: there are incentives for a programmer to be loyal to the folks who pay him. That does not necessarily translate into loyalty to a customer. Loyalty to a customer is more of a character trait. As for me, personally: I am a big proponent of professional ethics (work ethic, honor, integrity, etc), but my ethics are a personal choice and don’t necessarily reflect those of my employer. Same for my colleagues. They choose their own professional values/ethics.

Economics for consultants are a different dynamic than in-house staff. I (personally) feel like I have invested in building a good reputation in my community, and I believe it does add value to my resume.  Word-of-mouth pays-off for me, because of my reputational investments. I’ve been playing the long-game for a long time.

I suppose some of my examples here, might seem a bit pessimistic. After all, not all IT outsourcing goes badly. Many projects (staffed with contractors) go well, and even when they don’t, there is a good chance that there will be (several) responsible persons, who will feel honor-bound to do-the-right-thing.

Then again, when you see a company who is being successful with temp-staff, it is probably more than just luck. Most likely, you will also find someone in-house, behind the scenes, keeping things rolling smoothly and counting-beans properly.  That person is probably the one shouldering the responsibility.

[TLDR] Bottom line: Success requires responsibility. If you don’t have it, don’t expect your contractors to have it.  You cannot outsource responsibility. It doesn’t work.

Discretionary development

*** Disclaimer: this is not about my current team. It is about all teams, anywhere ***

Before you say it, I know what you are thinking. Bear with me for a moment please.

The first team that I lead, where I was officially sanctioned to do “discretionary development” was 15 years ago, and it worked great! Since then, it has been a hard sell, which is pretty disappointing.

The Problem: It is pretty common for dev teams to become organized to-the-point-where all work comes from prod-support or feature requests. Those come from the top, and get routed through BAs & tracked in work queues (in Jira or DevOps, etc).

Staying organized, orderly and predictable definitely has obvious benefits, but there is also a down-side. This structure usually prevents or blocks the developers’ from “coming up with” their own feature ideas or other improvements. If (when) a developer actually gets a good idea, or sees something wrong, the developer could request an audience with the person in-charge and is (usually) promptly told to “return to your desk and just do the work already assigned”.

So what’s the problem with that?

Developers have daily contact with systems, corresponding code & data. They will gain intimate knowledge of a system and come-across & observe “things that are wrong” or other shortcomings / problems within a project, program or system. Their unique perspective allows them to observe things non-programmers cannot (eg. might require a deep technical background to understand). Developers will also think-up utilities, upgrades, improvements, clean-ups and other ways to show craftsmanship, ownership and professionalism. Likewise, these kinds-of-things just aren’t going to occur to non-technical folks and therefore, probably will not be solicited or valued.

If you’re lucky, you might ask a programmer to explain why a proposed change will add value … and he actually will be able to express or explain it well. Unfortunately, communicating stuff like this (to non-technical people), isn’t really the strong-suit of most developers. Probably what would happen is, the developer will spout-out a bunch of jargon, and people won’t “get it”. If pressed, the developer will probably simplify the explanation to good-ole hyperbole, “Its good because you really, really REALLY need it! It is SUPER important!!” 🙂

How to manage it

Grant the developers a budget, like 10% of their weekly time, dedicated to development tasks/efforts of their choosing. It has to be work-related and it must be tracked, but they get to pick the work, define requirements, tests, objectives and priority. Give opportunities for developers to distinguish themselves and the project will be something they can be proud-of and care (more) about. Encourage developers to grow themselves by thinking higher thoughts.

Unexpected additional ROI

The obvious ROI is that the developers will make a system work-better, because “improvement” is now part of the job, and good ideas are welcomed from anyone. When excellence is everyone’s duty, you will get a better product, and the developers will try-harder and care-more.

The unexpected ROI happens when leadership/management learns from this. Hearing what the developers are thinking, isn’t the same as understanding the results. When you track the work, you can measure the ROI. Your next project might be significantly better because we all learned subtle (but good) things. You tried some of the ideas, and you saw where the ROI showed-up (which you otherwise might not have noticed). On top of that, you have conditioned the developers to teach you about their magic tricks, and maybe even understand it better.

Management now knows the names of these magic tricks, can inventory them, and communicate them. They are new tools in a PM’s toolbox.

…or not?

Believe it or not, I have observed developers who were aware of significant (underlying) needs within a system, but could not convince their leaders … so, they had to sneak-in several improvements. It was nuts. The developers were afraid of being punished for doing something necessary, but did it anyway. Management had no-idea why some projects flourished and others flopped. But they could’ve.

Don’t treat developers like code-jockeys. Give them opportunities to demonstrate craftsmanship, and take pride in their work. If they can’t express themselves eloquently or explain technical acrobatics to you, work with them on that. You will get better developers, better systems and better teams.

Selling snake oil or just being pedantic

Glossary:
Selling snake oil = deceiving folks
Pedantic is a fun word. Basically it means: using fancy words to impress people. So, using the word pedantic sort-of means you are being pedantic. Ha. Fun.

IT work is often some braniac stuff and IT folks tend to use a lot of complicated talk, but they aren’t alone. There are a lot of scientific, financial, technology, medical, legal fields (you get the point) who seem to talk over-your-head sometimes. Work-talk is often laden with industry jargon, but only because it is usually easier to say “you need more SSDs in your SAN” than it is to explain why a database is too slow, but $5 k of parts will make folks happy again. Don’t get me started on the medical field and their use of Latin to describe parts, sub-parts and sub-sub-parts of people. It seems excessive, but once you learn the terms, it makes sense why any of it is necessary.

Sometimes all of that jargon (industry language) will turn smiles upside down. If you’ve ever been sold some “snake oil” (ie. some pricey BS that didn’t fix anything), then maybe it will make you more wary, and perhaps even suspicious of folks who throw around complicated/confusing “sciencey” words that go-over-your-head, and seem impressive. I am a big fan of the “buyer beware” mindset, no-matter who I’m talking to.

At one point in my career, I was brought into a troubled project to solve things and complete the project. I thought I had found the root causes, so I had a meeting with the CEO to explain the problem and the solution. I was floored when she suggested that I was trying to sell her some snake-oil, and I needed to stow all of my fancy terms. All of my “slick talk” wasn’t going to fix the real problem here.
Ha! In a way, she actually did reveal the true root-cause. (ehem). Right? I was way-off, but so was she.

My uncle Jim used to say (jokingly) “if you can’t dazzle them with brilliance, baffle them with BS”. Thinking back, um, I don’t think he was actually suggesting I try it myself. He was (sort-of) warning me to be discerning. I would’ve preferred some advice about how to discern those two. Therein lies the problem, I guess. Words are easy, but understanding, that is the real challenge. At least I could be more wary and cautious.

Bottom line…just because someone is using a bunch of fancy-talk doesn’t necessarily mean they are selling you some snake oil. Ask for details, bring-along a friend who speaks the same / similar jargon, ask for examples. Maybe even ask for a list of terms to learn or keywords. Read-up-on those terms / concepts.

Sometimes folks will get pedantic to impress you, maybe to sell you something, even if it is only a concept. Sometimes they are just trying to communicate effectively, and failing at it. Learning industry jargon can be a powerful thing. It is only as expensive as your time, as much as it takes for you to learn it.

30 hour work week? but what about…

The 40 hour work week. Most of my career, I’ve heard folks talking about doing-away-with-it. I’ve even had discussions with colleagues about any differences between “putting-in 40 hours” vs “actual productive time”. Like “hey, if I can get my work done in 30 hours, then why do I have to fill a chair or punch a clock (or whatever) to fill 40? Maybe I’m more productive than others and I can complete my work in 30 or 25 or whatever.” (they say that, not me)

Alright, let’s consider this concept for a moment, and how it would work: You are assigned some work, and you just have to get it done. If it takes 40 or 30 or 50, it is what it is. Obviously, employees and management are guaranteed to disagree about “the right amount of work” in a week. Since the goal is to trade 1-week’s work for 1-week’s pay, then it creates an incentive for you to work-as-little-as-possible, and management has an incentive to squeeze more work from you. You both want the best value, and you both have incentives, but not because of money now. In this model, the amount of money won’t change because of the volume/quantity or quality of work. It is only “I got my work done”.

Really, if you think about it, in this sort of employment/work model, employees would be working more-like contractors than employees. Folks bid for work, negotiate a price/hours, and fulfil that obligation, however-long that takes. The concept sounds nice, but again, it goes-back-to negotiating for the best deal. When I owned my own company, I did this all-of-the-time. There was a lot of learning (on my part), (as-in: hard lessons-learned). A few of my customers were really honest and I reciprocated. I loved working with them and gave them my preferred time and priority. Other customers were pretty shrewd. I was glad when I was done working with them, because they left me feeling overworked and underpaid. Work like that is what eventually motivated me to get out of that role. I’m just not the kind of person who will prosper in that kind of model. I’m not sure I want to be, either.

What if you get a work-arrangement like that? Except, imagine you only have one customer: your employer. If they are more-shrewd than you, you may find yourself getting a bad deal, and feeling over-worked. Could you re-negotiate for fewer hours for less pay? Maybe. That would be some remarkable honesty. Not impossible, but remarkable for sure. In social media, I see a lot of people who threaten to leave, or resort to some passive-aggressive behaviors. Honestly, in my mind, this is how I would expect this sort of thing to turn bad. I’m not an optimist when it comes to business and management. I don’t mean that in a rude or mean way. This is how business works most of the time.

So yeah. Death of the 40 hour work week might sound nice. If you are only interested in less-work, and not interested in advancement, pay, recognition, responsibility, career-path stuff, then sure. Easy peasy. However, if you want “a little more” someday, then take a moment to think about what you are trading and if you really want to get the half-empty part of the glass.

How to get value out of interns

*** Disclaimer: This is about all companies everywhere, not just the one where I work right now ***

Definition: Interns/co-ops are usually college students, recent-college-grads (RCGs) or sometimes, just a person interested in trying your line-of-work, but needs practical experience. The intern works for you for some period of time, usually 4-6 month cycles (eg. semesters). It is sort-of a “try before you buy”. Upon completion, you both decide if you want to hire, or move-on.

Pre: Before you can get value out of an intern, it is critical (and a little obvious) that you BOTH want to get some value out of it. I want to emphasize “both”.

Intern’s Value – eg. What’s in it for me (the intern)?

1. The first, and most obvious is money. Like duh. There are harder ways to earn money, for sure. An internship sounds like a much better deal than an ordinary summer job. Guess what? Money is the least-valuable reward that an intern can get. The work that an intern will do, is probably going to be the beginning of a career.
2. The biggest prize is “resume candy”. Anyone with a blank (or sparse) resume will find it hard to land a dream-job (unless your family/friends hook you up). Nobody wants to be your first employer because it is all “investment” from the employer’s side, and it takes a while before you will show ROI. So, if you are lucky enough to score an internship, consider your good fortune and don’t screw it up for the next guy by being a putz. Please try to give these philanthropists some kind of ROI.
3. Relevant experience is the most-rare. I say this because “real engineer work” is usually over-the-head-of an intern. Think what happens if you give [prod server access] to somebody with no-experience. (** shiver **). Yikes. But it does happen for some interns, just not on day-1. Some receive great opportunities like this, by plain-luck, and some genuinely earn it.
4. Other bonuses could be: receiving mentoring, advice for navigating corporate seas (and maybe corresponding storms) and the opportunity to observe professional and successful people. (ie, the kind of person you could be someday)

Corporate Value

1. Ah. This is a tough one, because it is mostly “give”. Oh and also giving. Did I mention giving? Yeah. The more technical or complex the job/work is, the longer it will take to get ROI. Because some stuff is complicated and delicate and you can’t take a chance on letting a noob crash your servers, or accidentally screw up your builds, performance drain, security caveats, etc. It just requires lots of investment. The dream is: maybe there could be some ROI. But it is a gamble. Everyone involved needs to have expectations set. Be realistic and focus on gaining the outcome that you want.
2. Reputation – When I was a senior in engineering school, all of my classmates were talking about “where are you going?” “Who do I want to work-for, and who should I avoid?”. So having a good corporate reputation could help attract better noobs. Hearts & minds.
3. Known-quantity – Once you’ve invested in a person, you have a good idea who you are hiring. You did the “try”, so there is much less risk for the “buy”. Interns would prefer to work for you too because they also know your company and (natural) fear-of-the-unknown is less of a factor.
4. Value/ROI – If you really did a good job of mentoring / raising / investing-in the intern, they will probably have skills above their resume & paygrade. Your team can reap the benefits now.

Planning for value

Breaking-in an intern is a little like starting a new gym/workout routine, you start small and build upon it. The base strategy is to build positive momentum: accomplishments & success. Regardless of what your company and department really needs right now (wrt skills & progress), your intern will need tasks which are certainly completable by someone with little experience. This may (probably will) require concerted planning and strategy.

Here are a few tasks, with increasing complexity, designed to get small wins and increase complexity gradually.

1. Easy – Any noob should be able to complete without guidance or research
   – Log aggregator – find log files, copy them from remote to local
   – Log summary – count similar messages, group by day, find “hot-ones”, top-ten, new fires
2. Improvements – “now that this works, let’s make it better”
   – Design improvements
   – Better features for an existing program (scheduler, compare yesterday’s summary to today’s, email a summarized report to someone, history search for server/error logs)
3. Realistic 101 – Make somethings simple for another team.
   – Pick a real requirement for a real project, something small
   – A game called “read the error log and find the corresponding line of code”
4. Research – use some interesting new tech to make something simple
   – Understand how the new tech works
   – How to apply it
   – Deal with new quirks (do this, don’t-do this, can’t do this)
5. Maintenance – simple fix to something in-use which was written by someone else
   – Support “line 2” (ITIL intermediate level). Can you fix it or do you escalate it (with notes)?
   – Minimal changes (fewest lines of code)
   – Expect a noob to eventually suggest “rewrite the whole thing”. Explain why not.

With these tasks, keep-in-mind that the intern will often a) not know where to get started, b) get stuck and not know how to get un-stuck, c) be bashful about admitting it, d) need frequent guidance (more frequent than either of you may expect), maybe a little hand-holding at times, e) need mentoring about how to attack a problem from different directions, dissect a problem, divide and conquer, diagnose a problem, f) need mentoring about people: manners, when to stay quiet and when to speak, be respectful, humble, be prepared, g) corporate stuff like meetings, status, timesheets, vacation, social, work-appropriate stuff

Having an intern in your department can be a complete waste of time, or a valuable experience. The key differentiator is mindset and preparation. Applying a half-effort will probably yield less-than a half value. So if you choose to do it, choose to do it well, and earn a win.

Getting IIS to authenticate to your DB without a password

Before I start, yes, I know this is not a good security practice. I will explain why, at the end. This is meant for Dev & Test servers, because those usually don’t require strict security. Dev environments are usually a fine place to apply the kiss principal.

Mostly, this blog-post is for future-me. I’ve probably done stuff exactly like this, dozens of times, and described it to dozens of people, but I don’t have good notes on it anywhere. I seem to forget the process each time, and I have to re-discover it. Next time I can look it up here instead. If you also find it useful, that’s great too.

How it works

A SQL server can treat an IIS server (or app within IIS) as if it is just one single domain user. That way your DBA doesn’t have to make a pesky (SQL Server native) bot account (login/pw) for your program’s connection string, which will probably end-up (in plain-text) in your config file. That always feels gross.

I know what you’re thinking; instead of a bot account, or doing this stuff, we could use Kerberos to allow IIS to pass-through domain credentials to SQL server (also known as a “double hop”), but that doesn’t work as nicely/seamlessly with full-stack (js) apps. Machine authentication is pretty easy and still makes sense in some scenarios, like for full-stack stuff, imo. (using SAML with your API service, etc)

IIS config

Objective: Allow IIS to authenticate/connect directly to SQL server, as IIS’s machine account (ie, the web server’s domain name)

1. IIS Application Pool identity – This is the magic sauce which is easy to overlook (or difficult to see).
   Set up a new IIS app pool for your web app.
   Change “Advanced Settings”, set the Application Pool Identity to use the “built-in account” called “NetworkService”
   
   
   …and set your IIS web app to use this new Application pool
   
   
2. Anonymous – It might seem better to do pass-through authentication, which makes each user log-in with their own domain credentials, and then pass those through to SQL server. However, that is called a “double-hop” scenario. It is a hassle, and doesn’t really work well for “full stack” (js) apps. For this example, we will keep it simple and just do anonymous (my full-stack app will handle 3PA w SAML)
   

SQL server config

Objective: Create a SQL account for your IIS server (treating the server like it is a person or something), and grant permission(s) to database(s)

1. SQL Server, “Security” (for the whole server), create a new login for your web server.
   In this example, I have a web server called “WebServerDev01” on MyDomain. So the domain account for my server will be [MyDomain\WebServerDev01$].
   The $ suffix means this domain account is a server and not an actual person. AD seems to add that or require it. This is the secret handshake that gets SQL server to recognize your entire server as if it was one account.
   
   Also in SQL Server, Security (for the whole DB server), grant permission (for our new server account) to access any databases which will be used by our web server. Ideally, this will be the db_reader and db_writer roles, but if you are using Stored Procedures, this could get pretty involved.
   [ picture below ]
   
2. DB, Security, Users – grant permissions (roles, tables, SPs)

Testing

Ideally, now you should be able to just open your app and * Ta-da! * it magically works. However, you might need to adjust your configs (connectionString), or other settings, permissions (grant exec for your SPs) etc.

So, why don’t you want this in prod?

IKR. This was pretty simple and since no clear-text passwords are sitting unencrypted in your web.config, this seems pretty secure. Right? Well, not exactly. Let me talk about a few caveats that we just sorta opened up, and why/when that might be a bad thing.

• The whole web server at once – A web server can hold a lot of stuff. A sneaky person (hacker, developer, etc. who has gained access to your web server’s file system) in theory, could just simply put any sort of app anywhere on your web server. All apps on your web server would have permission to get to your DB and it would be difficult to distinguish between any of the apps on that server.
  Yeah, I know; if somebody is already on your server, don’t they pretty much have anything they need to get into your DB anyway? Well, maybe. However, I’ve seen a Sr developer/admin make a simple/honest mistake during a deployment. It wasn’t malicious, but because of the machine-account, it was still frustrating and elusive.
• Least privilege – On the SQL server side, if you are using an ORM or EF (or something) and not using SPs, it will be easy to manage, by granting read/write. If you are using Stored Procedures, managing (granting) permissions to all of those fellers (SPs) will drive you nuts. You might be tempted to grant “db_owner”, y’know, just to simplify things. but that really means any app could also alter tables, create SPs, drop stuff, or fully rampage on your DB. Keeping things nice & safe will take away all of the fun.

TLDR: Easy stuff is typically not very secure. This fits that rule. I don’t sweat my dev server(s) very much, usually. However, in prod, I will put-in more effort for security stuff, and so should you. 🙂
Stay leet!

Fritzing 8-channel relay part

A few years back, I made some Fritzing parts for 2-channel and 4-channel relays, and a few people asked me to make an 8-channel part too. Let me tell you, there is a real learning-curve to making these. Let’s just say Inkscape only got me 75% done, and the rest had to be done in notepad. My head is melting at the thought of it. But yeah, I finally got it done.

You can download it from my OneDrive.

To install it, just download & save the (downloaded) file (above). Unzip the download. From the upper-right panel in Fritzing “Parts”, pick the “Contrib” tab, right click, “Import”, then find the file that you just downloaded and unzipped.

It should show up with the other parts from now on.

Oh, if any of you have any interest in making your own Fritzing parts, and are getting stuck like I was, leave a comment. I can make another blog post explaining what kind of sorcery would require me to use notepad for editing a SVG file. 😀

CS0411 The type arguments for method … cannot be inferred from the usage

Evil. I really hate vague error messages. Especially when you search goog, bing, stackover and you find dozens of people talking about it, but none of it is similar to your code, and just frustrates you as you search, and keep finding the wrong help.

My head was melting for 2 days on this one. It is especially stupid, because I made some relatively minor changes, and this goshdarn error showed up all over the place, in code that I didn’t touch.

Here is the error showing up in Visual Studio (a dozen times)

CS0411 The type arguments for method 'TypeInference.CreatePropertyColumn <T, TProperty>(RenderTreeBuilder, int, T, int, Expression<Func<T, TProperty> >, int, string, int, bool?, int, bool)' cannot be inferred from the usage. Try specifying the type arguments explicitly.

This was my code:

The red (error) marker was over a function name (OnClick="@AddPerson"). So I wasted an entire day trying to refactor, and move code, and create references and lambdas, and other wrong-answers. Somehow, the compiler kept adding more errors for every change. Which also made no-sense. The problem didn’t seem to be related to this function or its implementation or the way I referenced it.

The change that I made (before these errors showed up), was I refactored a model class, by using a function for IsInactive instead of a property. I also refactored/expanded a few other properties; like I made Company into Companies (a list of companies). Both of these changes were simple, and I should’ve known which corresponding changes were necessary in my code/forms, but I was called-away-from my work before I could complete the rest of my changes. Monday, I got to work, couldn’t remember what I was doing, so I just started with a compile/rebuild. It gave me these vague errors, and couldn’t find any useful hints online. Bad monday, starting at 8:15am.

TLDR / Solution: As I mentioned, IsInactive is now a function. The solution was to put parens after IsInactive(), and the error went away. Likewise, other places in my code, I just had to look around for brown text and put parens after it. It was such a simple answer, but no-one had suggested it online.

Coincidentally, hovering over the code (which was not marked as part of the error) gave me a hint, but I didn’t think it was part of the problem because, duh, it wasn’t marked.

Explanation: The error message was trying to tell me (since I left-off the parens), the compiler thought I wanted a reference to a function instead of the output from the function. So it was trying to make a delegate, which is nonsense and wouldn’t really work, because you can’t display a function reference (delegate) in a grid. Obviously.

Anyway, if you are also being baffled by this obnoxious error, check for flaws just-after the marked code instead of looking at the part which is marked.

Solving a problem you don’t have

New stuff is constantly appearing in the software dev world. Like with anything new, it is exciting to learn and experience it, but I feel like people don’t ask the question behind the question, often enough. I probably can’t count the number of times I’ve had discussion which went this way:

Programmer 1: "We really need to start using Jingle-Jangle JS (et al). It is so-o-o-o hawt! We should ditch the trusty stuff we currently have and fully switch over to Jingle-Jangle"
Me: "Hmm, your suggestion sounds like a lot of work. Throwing-away all of our stuff (which currently is working-fine btw) and starting-over is not trivial. Are we sure it is worth the investment?"
Programmer 1: "Oh yeah, for sure! This product prevents scurvy, cures kukamunga-phobia, and protects you from the effects of anti-gravity. It is amazing. I can't believe we've survived this long without it!"
Me: "I don't think we are suffering from the things you just said. Does it solve any of the problems that we currently do have?"
Programmer 1: "You betcha!"
Me: "Please elaborate"
Programmer 1: (lists other problems that we don't have)
Me: (starts sounding like a broken record)
Programmer 1: "Why are you so resistant to change? This seems un-characteristic of you!"
Me: (feeling a little defensive) "I'm not being resistant. I just want to go-in with eyes-wide-open. We will probably have to justify this to our superiors/leaders. I intend to be forthright about it."

Anatomy of the problem

The underlying-cause behind my resistance is not because I’ve lost my technical progressive attitude. Not a chance of that happening! I fully understand what it takes to remain employable and relevant in the IT field. However, I do recognize that new tech often looks like a golden hammer, and it makes you want to start pounding nails. I’m sure there are a lot of “nails” shops and they love their nails. Maybe you are convinced of the merits of pounding nails. I can empathize with you, but the reality is: there are lots of places which don’t use nails. Our company/dept is a bolts & screws place. Even if you figure out how to screw-in a nail or hammer-in a bolt, it would be impressive, but it isn’t going to be as effective as the screws & bolts (and matching tools) which we are already using.

What if the whole world is (seemingly) switching over to Jingle-jangle.js… Could a reasonable person consider it prudent to stick-with-what-we-have, and ignore Jingle-jangle?! I’ll still say “it depends”.

Solution du-jour

Goog, Amaz, Faceboo and lots of other enormous organizations are using (and even creating) some cool and sparkly new tech. They are undeniable industry leaders. Clearly they are doing lots of correct stuff. No doubts. However, enormous companies will implicitly encounter problems which smaller/regional companies will not. There are significant differences between a team of 5-10 people who are maintaining apps for a small-to-mid-sized company, vs a tech corporation with thousands of programmers working on the same app simultaneously. Some IT skills are not dependent on team size, and some are.

Problems of scale, like this, are mostly unique to big companies. Big companies can create effective processes and practices which are useful for all-sorts-of-things, and may translate nicely onto any business, however they also have layers of bureaucracy which are necessary to them, to maintain order, but would be senseless to smaller organizations who are able to accomplish the same work on a naturally (smaller) more-manageable scale.

Generally speaking, it is difficult to tell (on the surface) what kind problem is being solved by a methodology or tech-stack, etc. However, if you take the time to understand it (it’s history, progression, etc), you have a better chance of understanding “what problem is this designed to solve?” and whether you have that problem too.

When you understand, you can resist the temptation to reach for the next golden hammer, and solve problems that you don’t have.