Tag: software development

  • Converting Types in C#

    I am not a great software developer. I’m OK, and I do know how to use Google and Stack Overflow well. Maybe my best skill is wording searches well? In any case, I’ve had to write a bit of C# lately to build an app for my Zero Downtime talk.

    In no way am I an expert on this stuff, but I learned a few things while working on the client. One of these was how to get to/from various datatypes. Not a complex skill, but since I do it rarely, I decided to do a quick blog.

    Creating Strings

    I actually remembered how to take a number and convert it to a string. The ToString() method works on many  items. In my case, I used some variables as numerics, often a zero or one, but I wanted to display these in a textbox. To do that, I needed something like this:

    txtRandom.Text = num.ToString();

    Easy enough to write, but other items were more complex.

    Strings to Int

    I only had to go the reverse way a few times, but found there was no ToInt32() or similar. I was hoping for one, but a little google query helped me realize this is what I needed?

    cmd.Parameters.Add("@year", SqlDbType.Int).Value = Convert.ToInt32(txtYear.Text);

    In this case, I was adding an integer parameter from a value in a textbox, which was a strong. The Convert class has a ToInt32() method I used.

    String to Date

    In one demo I move to a date as a parameter, again getting a value from a string textbox. This was yet another method. In this case, there is a DateTime class with a Parse() method. I used it as such:

    cmd.Parameters.Add("@start", SqlDbType.DateTime).Value = DateTime.Parse(txtStart.Text);

    This worked great.

    NULLs

    One other item I needed was passing a NULL value to a proc. Part of zero downtime deployments involve staging your changes, and that sometimes means altering which parameters you use and sending in other values. In this case, I found a DBNull class with a value property. I passed null parameter values like this:

    cmd.Parameters.Add("@year", SqlDbType.Int).Value = DBNull.Value;

    More

    There are obviously other conversions, but I’ll learn those as I need them. I know how to phrase a quick question and read through StackOverflow to find code I need and modify it. I’m good at asking questions and listening.

    If you have advice, please leave me a comment. I had some fun doing this, and I’m glad I didn’t need to bother too many people to get this working.

  • Building Recommended Software Practices

    Many of us work inside an organization that has a process for building and deploying software. We may find our org doing this well, or we may feel our process is poor with lots of room for improvement.

    A lot of the discussion around how to be better at building software in the last ten years has been around the philosophy of DevOps. This concept doesn’t really prescribe how to build software, but give you goals to aim for. That means you still need to take the ideas of flow, feedback, and learning and decide how you implement them with your staff. What practices do you follow to ensure you can deploy quickly anytime your code is done? These can include ensuring you’ve tested code, getting feedback from customers, and more.

    I ran across a post on recommended software engineering practices for an organization. The list includes seven things you should do:

    1. Keep documentation in the code repo
    2. Have a mechanism for test data creation
    3. Use rock solid database migrations
    4. Create templates for new projects
    5. Automate code formatting
    6. Automate a process for new dev environments
    7. Automate preview environments

    This is a set of things I often preach to customers as well, especially 2, 3, 6, and 7. I often focus on the database and having curated test data, migrations you can count on and easy setup is important. And, of course, with SQL Prompt, you don’t need formatting ;). Just kidding, that’s important, too.

    These are solid practices, and none of them are that hard to set up, but they do require some discipline and willingness to work as a team and maintain your process across time. Each of these items needs some care and feeding across time to remain relevant and helpful to your staff.

    Do you have good software engineering practices? Are you proud of them and would you bring them to a new position? Or perhaps you wish your team would adopt better habits and a different mentality towards building software.

    Steve Jones

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

  • Coding Magic Values

    It’s 2023. I would hope all software developers would learn that hard coding specific values in your system is more likely to cause issues than not. Across the years, we’ve learned not everything is installed on the c: drive, or that not everyone wants to put all data in a Documents folder (or in OneDrive). We’ve learned that any sort of magic number is poor practice, and we ought to know that hard-coded names are problematic as well.

    Yet, we still see it happening.

    This week I was reading about an admin issue in the Microsoft TechCommunity. This is related to Azure Managed Instance, but it’s really an In-Memory OLTP issue. That was introduced in SQL Server 2014, so I know the code for this was likely written in the 2011-2013 timeframe, but how can this type of issue get through code review and be released?

    In this case, the name of a filegroup is set specifically to XTP. It’s a logical name, and I’m sure that some developer thought that things might be faster with a known location. That doesn’t make sense, and while this might not be an issue for most customers, I’m sure there have been some databases built with a filegroup called XTP. After all, there are companies named XTP. What about if this feature evolves to allow a second filegroup, maybe because of some distributed architecture need in the future? Are there then code paths looking for XTP or XTP2?

    As much as possible, avoid coding values in your code that a user might enter as data. Names, paths, etc. Just don’t do it. Use variables, which are in every language, and let those values be read from the environment. This ensures that you don’t end up with weird support requests from customers because they chose the same value you did.

    Steve Jones

  • Forgoing Tech Investments

    The US was hit with a number of storms over the Christmas holiday weekend. This disrupted air travel for many airlines and their customers, but one of the worst hit was Southwest Airlines. They accounted for most of the cancellations, over half of their scheduled flights at one point.

    A number of places reported talking with Southwest employees who blamed the lack of tech investment by Southwest over time, noting this caught up with them. The Chief Operating Officer disagreed, saying that their scheduling system is the best in the world, even as the CEO noted that their scheduling software couldn’t keep up and they fell back to manual operations.

    Most of us likely have no idea of how Southwest software works or the scope of the problem. This airline does tend to operate differently than many others in that they mostly fly point to point, rather than using hubs. Possibly they have the best point-to-point scheduling software in the world, but it still couldn’t keep up with the storms covering much of the US.

    There’s an interesting perspective on Facebook, supposedly from a pilot with 35 years of experience with SouthWest. If you don’t want to click, his view is the hands-on CEO retired years ago and accountants were appointed as CEO and COO. They improved the money flow, but neglected investments in tech and weren’t aware of how the business really runs day to day. The infrastructure and software deteriorated, and they’ve had many small issues, but issues that were bigger than other airlines. They’ve started turning around with a CEO that is more hands-on, but they’re digging out of a hole.

    Like many of you, I’ve built and operated software over the years. I sometimes realize just how hard it can be to keep up with the demands of customers for adjusting how our systems work. I also know that it’s easy to slow your investment in a system that appears to works and limit your efforts to just maintenance work. Allan Hirt wrote about this.

    This does bring up the issue of investing in systems and maintaining them over time. I see why many companies would prefer to purchase software and let someone else manage the investment in ongoing development. I also know that for companies that see software as strategic, likely there needs to be regular investment, upgrading and refactoring code, as well as finding ways to scale higher and use resources more efficiently. Especially for databases.

    The battle between enhancing software and reducing technical debt is a constant one. I see this struggle being one that project managers and developers never agree on, but in the companies that seem to thrive, there is a balance. Perhaps it’s splitting the sprints, perhaps it’s allocating regular time during each development period, or maybe there’s another way.

    One thing is certain. We need to find a balance. Otherwise we might get into the situation where a complete rewrite or replacement of software is warranted; a situation that is almost always very costly.

    Steve Jones

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