Steely Dan - Black Cow - Drum Sheet Music

I couldn't find this online anywhere, so I wrote it myself.

We’re not a software shop. Yes, you are.

One of the things that has bothered me over the course of my career is hearing statements like this:

“We’re not a software shop. We just make <product here>.”

The typical scenario for a statement like this is the “justification” of cutting corners on software development:

Since the company really does not develop software, it’s okay for all the other departments to come up with a project plan and how long it will take, then hand that date to the software development team. Never mind that the deadline is not enough time to produce a quality product; it’s just the software piece. It’s good project management to make the software team hurry and hit the deadline.

What’s worse, programmers even use this excuse. And the business loves that.

That is, until the business finds itself mired in constant support, production problems, using unreliable data, and feature enhancements taking longer and longer to complete. The business can think of their situation in these possible ways:

* This is normal. This is just how software development works. We have a lot of production issues, but our team works hard to constantly keep it running.

* The software development team used to be fast and good, but now they’re slow and write a lot of buggy software. They must not care as much as they used to. We need to push them even harder.

* We must have been approaching software development the wrong way. Let’s stop and analyze why things are this way, and see what we can do to develop software the right way.

That last bullet point is rare. Why? Because only companies that “get” software development would ask those questions. And those companies would have done it correctly in the first place. It can happen, though, if enlightened employees are hired during this process.

The first bullet point is an unfortunate situation. Things could be better, but no one sees it, and the business keeps moving, albeit at a slower and slower pace. This is just how things are.

The second bullet point is tragic. The software team has put themselves (yes, it’s their fault) in the terrible situation of having to hurry and create bad software, and for their efforts they are now not trusted by management. They’ll typically spend nights and weekends (and early mornings) fixing things, and adding new things, because that’s what it now takes to keep things running. And many times the development team will do this covertly, because they don’t want management to know that yet another problem occurred. In the end, the software team gets burned out trying to keep up this pace, or management replaces them with offshore developers.

When your company depends on the software that it writes to keep things running and profitable, I hate to break it to you, but you are indeed a software shop. You’re just not admitting it.

Deadlines as excuses for writing poor quality code? No.

Someone said this to me:

"We never get a chance to clean up ABC code or to refactor it.”

My reply:

The business will never explicitly give you that time. It’s up to you (indeed, all of us) as professional developers to not use deadlines as excuses. There is no deadline in the world that should cause a seasoned developer to duplicate code. It’s up to us, with a commitment to quality, to push back when we’re told to hurry. If we don’t do that, who will? It’s professional negligence to use deadlines as excuses. Most businesses think they have done good project management work if they get the developers to hurry and produce the end result more quickly. They don’t realize how much they’re hurting themselves in the long run by sacrificing maintainable code.

Many times deadlines are arbitrary guesses that folks came up with at the beginning of a project. They’re meaningless. They’re actually worse than meaningless because being forced to hit them is detrimental to quality. It’s okay to let the business know that the work won’t be done “on time.” Many developers think they’re trapped into hitting a deadline, when if they just did quality work, and explained the situation to the business, the “deadline” could be moved, or code could be time-boxed. Sacrificing quality, to the degree that I’ve seen in ABC code, should never be an option.

scriptcs in Two Minutes

Want to say you've used scriptcs? Follow this post and you can say that in about two minutes.

(For the longer version, go here: https://github.com/scriptcs/scriptcs)

At a command prompt, run this:

@powershell -NoProfile -ExecutionPolicy Unrestricted -Command "iex ((New-Object Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin

Then run this:

cinst scriptcs

That's it. Really. Now you can write C# at a command prompt:

C:\>scriptcs

scriptcs (ctrl-c or blank to exit)

> var message = "Hello, world!";

> Console.WriteLine(message);

Hello, world!

Want to save some C# and run it any time? Do this:

C:\Temp>copy con helloworld.csx

var message = "Hello, world!";

Console.WriteLine(message);

        1 file(s) copied.

C:\Temp>scriptcs helloworld.csx

Hello, world!

Note: I got an error when trying to run this at the root of the C: drive, so I just switched to my temp folder and it worked.

Enjoy!

An Alternative To Stacking Many KnownType Attributes

If you find yourself having to stack many KnownType attributes on a class that is sent over the wire for WCF communication, there is a slick alternative.

Instead of something like this:

You can specify a method to reflectively return all of the types for you:

And here is the GetDerivedTypes() extension method:

Now we no longer have to add new KnownType attibutes every time we have a new subtype. Nice, eh?

Curriculum Vitae - Bob Horn

See latest online resume (Jan 2022):
https://app.enhancv.com/share/be066243?utm_medium=growth&utm_campaign=share-resume&utm_source=dynamic

Bob Horn
rhornjr@gmail.com

Last updated: 18-Aug-2021

Objective

I want to be really, really good at what I do, and I want to be happy doing it. I love learning and I love sharing what I've learned. I want others to be excited about getting better at what they do. I want to help others be that way.

Education

Master of Science - Business Information Technology
Walsh College, Troy, MI
GPA: 4.0

Bachelor of Science - Computer Information Systems
Walsh College, Troy, MI
GPA: 3.81

Work

Proliant: Senior Software Engineer
Paylocity: Programmer
MEDsys: Director of Information Technology
First Solar: Developer IV (developer and architect)
Metavante: Programmer Analyst Specialist (developer and release management)
Maximum Data: Software Development and IT Manager
Dantom Systems: Development Manager and Developer
Case Consulting Group: Accountant and Developer

Technical Experience

Languages: C#, HTML, ASP.NET MVC, JavaScript, CSS, TSQL
Platforms: Windows, Linux
Concepts: Software development, leadership, teaching, design, architecture, project management, web, architecture

Project Experience

Architect: solar power plant energy prediction
ScrumMaster: manufacturing project - Lot Traceability
Developer: Many projects over many years

Presentations

Pluralsight Audition Video on Polymorphism (2013)
Web Development (June, 2016)
SignalR (June, 2013)
Project Maintainability Analysis (measuring OOP, SOLID, best practices) (May, 2013)
Windows 8 and JavaScript (March, 2013)
Clean Code and Design Patterns (June, 2012)
Design Patterns and OOP (January, 2011)
Chain of Responsibility Design Pattern (2009)

Other Activities/Hobbies

Blog: http://inaspiralarray.blogspot.com/
Open source project (Presto): https://presto.codeplex.com/
Reading: http://inaspiralarray.blogspot.com/2013/04/books-ive-read-software.html
StackOverflow reputation of 10,000+: http://stackoverflow.com/users/279516/bob-horn
CodeMash: 2011, 2012, 2013, 2014, 2015, 2016, 2017

Quick and Dirty ClickOnce Server

Disclaimer: This isn't necessarily the way a ClickOnce server should be set up. This is me doing the bare minimum, hacking around, just to get it up and running for someone to use quickly. If you're looking for best practice, go somewhere else.

On a server that was picked to be used as the ClickOnce server, create a folder to store the ClickOnce deployed application:

C:\ClickOnce\PrestoDashboard

Since I'm using AD authentication, I also set the security on the above folder to contain only those people that I wanted to access the app.

In the properties of the WPF app, set the location and then click Publish Now:

At this point I thought it would work, but I was getting errors when trying to access the location within my browser. So I set up a virtual directory in IIS:

I was getting an authorization error at this point, so I went into the Authentication properties of the virtual directory (screenshot above, right side) and enabled Windows Authentication.

Done: