Republish: Over-Engineering

It’s Black Friday, and a holiday in the US. I’m off today, no idea what we’re doing, but probably some horse chores and taking it easy.

You get over-engineering as a republish. I realized it was never on this site, so here it is:

Over-Engineering

This editorial was originally published on Jul 15, 2009. It is being re-run as Steve is on holiday.

I stumbled upon an old blog post by Neil Davidson that he recycled via Twitter. It was about design and how things bloat. In the post he references another blog by Moishe Lettvin , who worked on the Shutdown menu in Vista. Reading that post, I was amazed to find that 8 people directly and 43 people indirectly contributed to that feature over a year.

Really?

At first I had the amazing response that most people probably have of MS is obviously so (insert your four letter adjective here) blanked-up, no wonder Vista was late. However as I read through the comments, I saw so much disagreement over how the feature works, should work, compares with OS X, and more that I’m not sure so this was a year of development time wasted. (Note I don’t know the man-years spent on this, but I bet it’s > 1).

I haven’t built a lot of software in my career, especially large scale or shrink wrap software, and so perhaps I don’t really understand things. However I do think that we tend to over-engineer too often. I see people that try to design in every contingency, as well as think of every possible places things might go wrong. I have a simple mantra for you folks:

You can’t do it. Get over it and ship something.

It sounds simple, but it’s not. But it’s not necessarily naïve. I’ve seen too many people delay releasing something, trying desperately to get things right. They’re never right. They’re also never done, so you might as well ship something that’s 80% right and then plan on fixing it right away.

I know some people will disagree and say that things should be built right the first time. I don’t think they ever are. They can be built well, but they ought to be built quickly, and with a design that expects changes to be required in  a relatively short time frame after they’re released. This doesn’t work for all software, but I bet it works for a large class of applications that aren’t on the scale of SAP or Windows.

We can learn to code better, build more secure and stable software, but I don’t think we’ll ever cover all the bases. So why try? Build something that works most of the time and then refine it from there.

Posted in Editorial | Tagged | Comments Off on Republish: Over-Engineering

A New Word: Nachlophobia

nachlophobia – n. the fear that your deepest connections with people are ultimately pretty shallow, that although your relationships feel congenial in the moment, an audit of your life would reveal a smattering of low-interest holdings and uninvested windfall profits, which will indicate you were never really at risk of joy, sacrifice, or loss.

I don’t have nachlophobia. Maybe in my younger years, but I deeply value connections with those I choose to spend time with. I have learned to make an effort at events to spend significant time with a few people, even if this means I don’t get time with others.

I have no fear that I’m not risking anything; I am. I am truly saddened when my close friends experience pain and joyful for their success.

A few weeks ago at the PASS Summit, I spent an hour sitting in a mostly empty room with a friend, talking about life. We chat periodically, but we don’t see each other enough. It was worth every minute. I also had to go offsite to an event and another friend asked to ride with me. I was grateful for the company and conversation, something I don’t get enough of.

I hope none of you have nachlophobia. If you do, spend time building strong relationships, which are defined by you. It doesn’t matter how others feel about me, it’s about how I feel about them.

From the Dictionary of Obscure Sorrows

Posted in Blog | Tagged , | Comments Off on A New Word: Nachlophobia

Adding Test data to msdb.sysjobhistory

One of our internal people was looking to test some process in (I assume) Redgate Monitor and needed more job history than they had in msdb.sysjobhistory. They wanted to use SQL Data Generator to help, but couldn’t make it work.

This gives the solution I sketched for them. It can work with some other system tables, but not all. Many system tables do not allow user data to be inserted. Some do.

The Main Problem

The main problem here is that SQL Data Generator doesn’t see system tables. If I open a project in msdb, I see this:

2024-11_0297

That matches what I see in SSMS. Only user tables.

2024-11_0296

However, I know I can do this and it works.

INSERT INTO dbo.sysjobhistory
  (job_id, step_id, step_name, sql_message_id, sql_severity, message, run_status, run_date, run_time, run_duration, operator_id_emailed, operator_id_netsent, operator_id_paged, retries_attempted, server)
VALUES
  ('EA6B3BC3-D358-4B0C-A793-8C3C558098AB', 0, 'mystep', 0, 0, 'Executed as user: NT Service\SQLAgent$SQL2022. The job script encountered the following errors.'
  , 0, 20241111, 175438, 0, 0, 0, 0, 0, 'ARISTOTLE\SQL2022')

Now, how to get SQL Data Generator to help?

A Little System Table ETL

Since I know I can insert data into the table, how can I generate data? Apparently SQL Data Generator cannot read these tables, but I can use a trick that I’ve used in the past.

First, I’ll run this in msdb:

SELECT *
  INTO mysysjobhistory
  FROM dbo.sysjobhistory AS s
  WHERE 1 = 0

This code will make a copy of dbo.sysjobhistory with no data. However, this is a user table. Once I do this, now I can refresh SQL Data Generator and I can see my table.

2024-11_0094

Now I can use the settings to get the type of data I want. Here’s a preview of some data I set, using the data in my existing table.

2024-11_0095

Now, I can click generate data and I have data added to my user table. If I query this table, I see data:

2024-11_0096

The last step is to move this data. I’ll use this query:

INSERT dbo.sysjobhistory
   (job_id, step_id, step_name, sql_message_id, sql_severity, message, run_status, run_date, run_time, run_duration, operator_id_emailed, operator_id_netsent, operator_id_paged, retries_attempted, server)
SELECT job_id, step_id, step_name, sql_message_id, sql_severity, message, run_status, run_date, run_time, run_duration, operator_id_emailed, operator_id_netsent, operator_id_paged, retries_attempted, server
  FROM dbo.mysysjobhistory AS m

Once this runs, I can see the data in msdb.

2024-11_0097

Of course, I’d also have to populate sysjobs if I wanted this linked to a job and shown in the Agent Job History Viewer.

Summary

This post showed how I’ve sometimes worked in situations where I couldn’t directly access a table from an application. In this case, I want to get data into sysjobhistory, but SQL Data Generator doesn’t support that directly. My solution:

  1. make a copy of the table
  2. insert data into the copy
  3. move the data into the original

This has worked in a few situations as well where I might need to move/stage data before it gets into an application table. In this case, we wanted to generate some random history for Redgate Monitor to read.

This can work for other tables as well, as long as you can insert..select into them.

SQL Data Generator is a neat tool to generate data quickly for a variety of purposes in SQL Server. Give it a try, especially if you already have the Toolbelt Essentials.

Posted in Blog | Tagged , , , | Comments Off on Adding Test data to msdb.sysjobhistory

Have Grace

Thanksgiving is tomorrow in the US and it is supposed to be a holiday when we give thanks for our blessings in life. My wife usually has everyone in our family tell what they are thankful for this year. I also see many people posting things they are grateful for during the month of December.

Last month I was lucky enough to have dinner with Bob Ward and we were talking about some of the things we’d seen in travels, often some stressful times for ourselves or others. We’ve seen many people get upset or angry or have some other reaction. Both of us have some empathy for others, recognizing that we don’t really know their history or experiences, and it doesn’t make sense for us to get upset. If we knew those things,  we might better understand the reaction that someone displays to a situation.

Bob used a great phrase, saying that we should “have grace” when dealing with others.

I love that. I know I have stressed days, or grumpy days, or times when I’m not at my best behavior and I’d hope others would understand. I try to do the same for others, and I remind myself to “have grace” now when I see someone dealing with difficult situations.

I hope all of you enjoy the holidays this year, but if not, I hope others have grace when dealing with you. And I hope you remember to have grace with others.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | Comments Off on Have Grace