I know it’s been a long time since I last posted, but I think it is relevant to discuss training and education, especially in software development. This has been a topic weighing on my mind a lot the past several years.
In the past 20 years since I made the leap into my career path, I have witnessed many changes in technology. The microprocessor and the internet have taken over nearly every facet of our daily lives. It is quite remarkable where we came from to where we are today, and to think it has only been that short of a time while I’ve been a professional.
When I first started writing software, we didn’t have the rich toolsets we have now. We had some very basic compiler suites, or command line compilation using a text editor to edit the source files. We also didn’t have the libraries available today. Most problems we had to solve from scratch. Finally, to top it off, we didn’t have Google to save the day when we needed that snippet of code to hybridize into our own solution. We had to know how to write algorithms to solve problems. The solutions weren’t handed to us, and we weren’t coddled to the answer via great tools that auto complete our lines of code, and format our code and give us instant feedback to errors or omissions without compilation and trial and error.
I may sound like an codgidy old man, and maybe I am, but I think having to solve problems from scratch taught my generation a lot about problem solving. I think this is the magic bullet that is missing from the college curriculum, work training programs, or coding bootcamps. I think all of those things are great, and there is some foundational stuff there, but these folks are missing out on algorithm design. This is the foundation for which all software works. You have to be able to solve problems. You can’t just rely on Google or great tools to solve them for you.
So, you’re a Rockstar developer and you’ve constructed an app that is primed and ready to be the next big thing. All that stands between you and millions of users is deploying it to the cloud. While you’ve narrowed your choices to Microsoft Azure, Amazon Web Services (AWS), or Google Compute, you just aren’t sure about where to park your creation for the long haul. After all, you expect to be publishing new features and updates daily for quite some time. The future home of your masterpiece can’t slow you down on your quest to conquer the computing universe! You’ve done your pricing research and all three options are comparable, so really the decision comes down to first time configuration ease, first time deploy time, subsequent deploy times, and any other perks that might save you steps in the future as this juggernaut scales.
Well my friend, this guide was written for you!
Since you probably aren’t going to hand over the source code to your ultimate creation, for purposes of demonstration, we will call upon our old reliable and trusty friend, “Hello World”, written in C#, ASP.NET Core, and utilizing Visual Studio 2015.
This guide assumes you have accounts setup at Azure, AWS and Google Compute. For Azure, you’ll want to install the latest Azure SDK for Visual Studio 2015. For .NET Core, make sure you have installed Visual Studio Update 3 or greater. It’s also a good idea to do all of your updates for Visual Studio under Extensions and Updates.
First, we will deploy our web app to Microsoft Azure. One nice thing about deploying to Microsoft’s cloud service when using Microsoft’s development studio is that the two are very nicely integrated. The first advantage that Azure has over any other platform is in configuration. When you open Visual Studio to build your web app, click “New Project…”:
Next, select Templates->Visual C#->.NET Core->ASP.NET Core Web Application (.NET Core). Uncheck “Add Application Insights to project” and give your project the name “HelloWorldAzure”:
On the next screen, select “Web Application” and you’ll see in the bottom right quadrant of the screen, “Host in the cloud” is checked. This is great, because this helps us configure our cloud deployment without having to bounce between interfaces.
After clicking “OK”, the following screen loads. You’ll notice everything will preselect and fill. A unique name will be generated for your Web App Name. You can change this to whatever you want it to be as long as it is unique. Your subscription will preselect from the list, however if you have multiple subscriptions you’ll need to select the correct one. If already you already have a Resource Group and App Service Plan created in the same region, they will preselect. If not, you can select the correct one(s) or create new ones by clicking “New…”. For this example, we’ll create a new resource group and app service plan.
After I click “New…” on Resource Group, it asks for me to give the Resource Group a new name. I’ll choose HelloWorldAzureResourceGroup. After I click “New…” on App Service Plan, I get the following dialogue prepopulated with all of the options I need, so I’ll click “OK”.
Now that you see these changes to the Create App Service dialogue:
I now click the Create button and get a familiar progress dialogue:
At the completion of the progress dialog, our project is now created. To make this a real “Hello World” web app, navigate to the Index.cshtml view under Home and replace the HTML in the view with the following and save.
Now, it’s time to get our project deployed to Azure. First, right click on the project and click “Publish…”.
You’ll notice right away that all of the setup work took and the project is ready to publish.
As long as you don’t need to reconfigure you are safe to click Publish. After waiting a minute or so, your environment will be created in Azure and your project will be deployed. You’ll see in the bottom left corner of your Visual Studio and a browser will open with your website in it deployed on an azurewebsites.net domain.
There are many more Azure features to explore, but that summarizes the basics of getting a project published to the cloud.
AWS and Google Compute
To get a “Hello World” project ready for AWS or Google Compute, we need to bypass all of the Microsoft Azure platform integration during project creation. First start by reading the beginning of the Azure guide above, but name the project HelloWorld instead of HelloWorldAzure and when prompted to “Host in the cloud” uncheck that box.
I now click the OK button and get a familiar progress dialogue:
At the completion of the progress dialog, our project is now created. Just like in our Azure setup, to make this a real “Hello World” web app, navigate to the Index.cshtml view under Home and replace the HTML in the view with the following and save.
At this point, our project is now ready to deploy, but the process is different for each platform, while the overall process is going to be the same. First, we need to create a compute instance on each platform. Next, we need to configure that instance to receive our web application. Then we configure our application for deploying to that instance. Finally, we deploy to the instance by using the Publish wizard like we did in the Azure example, but our new publish profile will target our compute instance and not Azure.
The way we are going to get our application to AWS is to build an AWS EC2 instance and configure it for Web Deploy. To do this, we need to sign into our AWS Console. From here, click Services->EC2.
Click the blue “Launch Instance” button:
Scroll about halfway down the list and select:
By default, the AWS EC2 wizard will select t2.micro. This is fine for our purposes, but you can pick whichever computing power you think you’ll need here. Remember that you are building a virtual machine to run as a web server, so it needs to be able to support your application. In the future, you can tear it down and replace it, but these are considerations you’ll want to think through.
Next, you’ll need to configure your webserver. Click “Next: Configure Instance Details”.
Here you can configure many details about your web application, including number of instances and other details. For our purposes, we will leave the defaults and click “Next: Add Storage”.
Again, the defaults here are fine for our purposes, but you might want more or less storage, more volumes, different speeds, etc.. These are all things to consider. Click “Next: Add Tags”.
On this screen you can assign Tags to your EC2 instance. Tags are the way in AWS to help you identify your resources and categorize them for different purposes. For our example, click “Next: Configure Security Group”.
Finally, a screen we need to affect to get our app working. Since we are building a web server, we need to allow HTTP traffic at minimum, but we’ll also add web deploy traffic too. If you are going to configure your application for SSL/TLS or other ports and traffic, you’ll have more work to do here.
First, you’ll notice RDP is added already. This rule allows you to be able to use Remote Desktop to remotely administer your server. Leave this in there, we’ll need that access later, but change the Source to Anywhere.
Next, click “Add Rule” to add our HTTP rule. Scroll to HTTP in the drop down and that is all we need. It automatically sets up port 80, which is the default HTTP port. Again, use Source Anywhere.
For web deploy, click “Add Rule” and leave it as Custom TCP Rule. For the Port Range, pick 8172, which is what web deploy listens on. You guessed it, set the Source to Anywhere as well.
At this point, your screen should look like:
Click the blue “Review and Launch” button. On the next screen you can review what you have configured. Once you are satisfied, you can click the blue “Launch” button.
You’ll now be prompted to “Select an existing key pair or create a new key pair”. Once you’ve created a key pair, you can select it, but since this is our first time running through, we’ll “Create a new key pair”. To do so, give the key pair a name and click “Download Key Pair” to download the PEM file. You need to do this, because you won’t be able to do it later. You’ll need this file to be able to access your instance after it is created.
Once you download your PEM file and store it in a safe place, click the blue “Launch Instances” button. It’ll take a few minutes, but your instance will be created. Click the blue “View Instances” button at the bottom of the screen.
Next you’ll see your instance “Initializing” on the next screen:
Once the Status changes from “Initializing” to “2/2 checks passed”, your instance is ready to connect to and finish the configuration.
At this point, we will RDP to the server. To do this, right click on the instance and click “Connect”.
Click “Download Remote Desktop File”. The file will save by default to your downloads on your computer. Next, click “Get Password”. Now the PEM file we downloaded comes into play. You can either copy and paste the contents of the file into the next dialog or browse to the file and upload it. Either way, once you have it in the text box on the screen, click “Decrypt Password”.
Now you can get your password to use for the Administrator account. Open the RDP file and connect using this information. You’ll be prompted to accept the security certificate. Click “Yes”.
Because both AWS and Google Compute are so similar once you connect to the server to configure it, I’ll explain how to build a Google Compute instance next. You can skip to the Configure IIS headling if this doesn’t interest you.
To create a Google Compute instance, log in to your Google Compute Console. Click “Create Project” from the drop down at the top. You will be prompted to give your project a name. We’ll call this project “Hello World”. Google Compute will assign a project ID that is unique to this project.
Click “CREATE” and after about a minute you’ll be taken to the dashboard for your project.
Click the hamburger menu () at the top left and click:
From the Cloud Launcher, scroll to OS and click:
Then on the next screen click the blue “Launch on Compute Engine” button.
You’ll now be prompted to select your billing account.
Select it from the list and click “SET ACCOUNT”. You are now in the Google Compute Engine and your server is initializing:
Wait about another minute or so and you’ll be prompted to complete the setup. From this screen, you can change any settings you want, but for this example, check Allow HTTP traffic. If you were configuring this server for SSL/TLS you’d want to also check Allow HTTPS traffic too.
Once you’ve done this, click the blue “Create” button.
After clicking, you’ll be taken back to the VM Instances page. Creating your new server takes a few minutes. You can watch and wait on this screen.
Your sever is configured when it gets the green checkmark:
Now that our server is created, we need to open up a port in the network to allow Web Deploy. Click on the server name to take you to the edit screen. Scroll down to the network section and click the “default” link.
Scroll down to your firewall rules and click “Add firewall rule”.
Fill out your rule just like this:
When you are finished, click the blue Create button. Then click the back arrow 2 times to get you back to the VM Instances screen.
At this point, we need to configure a Windows account, so click on the server name to take you to the edit screen. Click on “Create or reset Windows password” at the top of the page.
Click “SET” and on the next screen copy the password from the dialog and click “CLOSE”.
Now that you have a windows account, you need to download the RDP file to connect to the server. To do this, click the RDP dropdown on the VM instances edit screen for your server. Then click “Download the RDP file”.
You may be prompted to login to your Google account again, but afterwards the file will download to your Downloads folder. Move this file to another location and open it. Use the username and password you created in the previous steps. You’ll be prompted to accept the security certificate. Click “Yes”.
Now that you have your compute instance created in either AWS or Google Compute and you have logged into your server, you need to configure your server to host your website. First, you need to go to Server Manager and click on Local Server. From the Manage menu, select “Add Roles and Features”. This opens the Add Roles and Features Wizard.
From here, click Next, then select Role-based or feature-based installation and click Next. On the next screen, select “Select a server from the server pool” and click Next.
From this screen you’ll need to select “Web Server” then click Add Features.
After that, click Next. On the next screen select ASP.NET 4.5 under .NET Framework 4.5 Features. We’ll install .NET Core on a different step.
Click Next. Then click Next on the following screen. Then you will have the Web Server installation tree. Click Next on this screen. Then click Install on the following screen.
Wait about one minute and the installation will finish. Click Close.
Follow the wizard to install. After the installation is complete, reboot your server.
Deploy to the Cloud
Regardless of if you chose AWS or Google Compute, now we need to configure our application to deploy to our compute instance.
In Visual Studio, right click on the project name and click Publish.
This opens the Publish wizard. Select Custom and then give your publish profile a name. I’ll use CloudDeploy as mine.
Click OK and for Publish method pick Web Deploy.
For Server, put in the IP address or host name of the compute instance. For “Site name” put in Default Web Site. For “User name” put in the user name (probably Administrator) and for Password put in the password. Check “Save password” and click “Validate Connection”.
At this point you will have to validate a certificate for Web Deploy. Be sure and check “Save this certificate for future sessions of Visual Studio”.
If everything went well so far, you’ll see:
Click Next. On this screen expand “File Publish Options” and check “Remove additional files at destination”. This will be useful when publishing updates to your application so you aren’t left with remnants of previous deployments.
Now click Publish. The publish will most likely error with an error code of ERROR_CERTIFICATE_VALIDATION_FAILED. This is expected because of the untrusted certificate issued by the compute instance. In your Solution Explorer, find your publish profile file with the .pubxml file extension. Open this, and add the following on a new line before the </PropertyGroup> tag.
Save the file, close it, right click on your project and click Publish again. Now when you click the Publish button the publish will succeed. Open your IP address or server host name in your browser and you should see your application:
Voila! You’re done! You have succeeded in building a web server on your platform of choice and deploying your application to the cloud.
Congratulations! You are now an expert on deploying your ASP.NET Core web application to Microsoft Azure, AWS, and Google Compute. As you can see, all three systems, with the proper configuration can accept your web application from Web Deploy and deploy and run with ease.
Comparing the different platforms, there is really not very much difference in configuration between AWS and Google Compute. They both are very powerful, and give you good wizards to walk through the setup on their websites. The only downside is having to RDP to the server to configure it, but these things can be scripted and probably should be scripted using a system like Chef or Jenkins to reduce user error.
Microsoft Azure seems to be the most direct way to deploy, but you’d expect that since you are using Microsoft Visual Studio to configure and deploy the application. Azure, from it’s tight integration, doesn’t give you the server level granular control right out of the box using an App Service, like we had on the other two platforms. Azure does have this capability using Web Roles or just building a VM and installing .NET Core and Web Deploy on the server like we did on the other platforms. Likewise, there are volumes of Chef recipes or different scripts online to build and tear down AWS or Google Compute servers.
Finally, your choice should come down to cost, preference and possibly geography, although all three of these platforms have great worldwide geographical coverage. You really can’t lose, so get out and take advantage of what ASP.NET Core and the cloud have to offer in rapid development, continuous integration and scale! Happy coding!
So much can be said about character. To me, it is the number one thing I look for in another person in any walk of life, not just professionally. Character is our moral fiber. It is what makes us who we are and it provides us what we need when we are at our whit’s end.
Mark Twain said, “It is curious that physical courage should be so common in the world and moral courage so rare.” I don’t know if it is so rare or it is just not advertised. Doing the right thing, being paitent and kind, being strong when the chips are on the line, these are things that just aren’t talked about. They are exactly the types of things I look for in those around me.
I am a huge football fan. My team I root for is the Kansas City Chiefs. In 1998, after a very good run in 1997 and a 13-3 regular season record and a disappointing loss to the division rival Denver Broncos in the divisional round of the playoffs, Marty Schottenheimer was going all-in to try and win a Super Bowl. He brought in several players of questionable character, but with above average talent. This move backfired and Marty experienced his first and only losing season in his coaching career, going 7-9. Marty went against his moral fiber and brought in players purely on talent. He never did this again in his other coaching stops. He only had one other losing season.
In my own career, I have spent much of the interview process talking with the candidate. I’ve been known to take a candidate to Starbucks and buy them a coffee and just try and get to know them. During nice weather, I might take them on a walk through the trails by our offices if their shoes are up for it. This approach tells me more about the person and I also get a feel for their qualifications. I can always coach them up or teach the person a skill, but I can’t teach them to be a person I trust with the operation and execution of my future and the futures of those I work with.
In short, when looking to who to surround yourself with, look to character before talent and you’ll do much better in the long run. I’ve mentioned George Washington as one historical person I’ve looked up to as a leader. He was quoted as saying, “It is better to be alone than in bad company.” There is so much truth in this short statement.
Everyone has heard the expression, “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime,” or some variation of this. In fact, it’s been quoted, paraphrased, blogged, memed and parodied so many times, it hardly seems blog post worthy anymore. The phrase itself is a fairly novel concept. The real reward in life is learning to be self sufficient and to not be dependent on others. This is truly where happiness comes from. A new penny loses it’s shine eventually and is just a penny, but if you know how to make that one penny into many pennies, the reward is so much greater. Blah, blah, blah, etcetera, etcetera, etcetera. We all know this, right?
When I got started in IT leadership, I was so obsessed with making sure things were handled to my standard that I hoarded much of the work. I would tell myself that I was protecting my employees from having to deal with such things, but in actuality I was hindering their development. There was the occasional employee I felt so comfortable with that I would hand one particular project to them and let them own it, but for the most part I felt like I had to have my hands on everything that was going on. I felt if I didn’t do this, we would fail. I felt such ownership over every piece of software, hardware, process, or procedure that I couldn’t let it go.
I can still remember having several conversations with my boss about delegation. We talked on the subject often, and I understood that it was something I needed to get better at, but I sure didn’t know how. How do you own something, and be responsible for it’s success and yet let other people do it? This concept was hard to grasp. It was hard to grasp for him too, but we both vowed to get better at it.
I remember seeing a program about George Washington once, and on the program they talked about his leadership style. George would gather those whose opinions he valued, hear them out and make a call. I visualize them in a circle around some old 1700’s wood table made from a tree trunk, standing of course, in full dress for the period. I picture them with their wigs and hats. George would address the group with the issue, and then he would back off and let them all talk about it. He would observe and in the end I picture him clearing his throat to a silence of the crowd and just telling them how it is. George took the opinions and ideas and formulated his own idea and then that is what happened. That is my image of a good leader. The thing was, George had those around him that he trusted to provide value. How did he get to that point? Sure you could say it was because he served in the trenches with them. You could say it was because George always had the absolute best around him at all times. The truth probably is that George did his best to teach them all to fish. He made them better, so in the end he was better at his job.
To come full circle, I think we can learn something from George Washington. For us to be the absolute best version of ourselves, it is our responsibility to teach everyone around us to fish. In business, now, I think I do a much better job of this. I give everyone who works for me the permission to fail. In fact, I encourage it. I want them to try to solve problems on their own. I tell them that my door is always open to talk through what they are working on, but in the end, they are the ones working on it. I will not do it for them, even at the expense of the project or a deadline. In my early days, I had no problem sitting down at my employee’s workstation and running through the solution to whatever problem they were working on and not thinking twice about it. Each time I did this, I was setting them back days, weeks, or months in their development and maturation as a technology professional. To be the best leader I can be, it is up to me to make those around me the absolute best they can be. If I do this, in the end, we will all reap the rewards of learning to fish.
In the fast paced world we live in it can be very easy to skip from one thing to the next and expect for things to work out or just flat out expect to win. I do this. I expect to win, no matter the situation. I can be teaching someone a skill, building something, playing a game, having an argument or even driving to work, I expect to win. I would argue, this isn’t a bad quality at all, except when you don’t recognize your accomplishments. Learning to celebrate success is truly what winning is about at any level.
It took me years to realize that sometimes winning can happen in losing too. No one celebrates losing. Losing imagery usually looks something like this:
Winning has become second nature to the Royals. How did they get to that after decades of losing? It’s my belief that winning for the Royals started while they were still losing ball games. The players they brought in and the players they had developed knew what winning was. It was something they lived and breathed everyday in their work ethic and execution. They knew, in order to be successful, winning is sacrifice, determination and hard work. It’s believing in yourself and your team.
I listen to many podcasts about leadership and I recall an interview with Joel Manby, who is the new CEO of SeaWorld Parks & Entertainment and former President and Chief Executive Officer of Herschend Family Entertainment. He says, “The enthusiasm of the guest experience can never rise higher than the enthusiasm of your own employees.” This is 100% true! The Royals displayed that when they were drawing 8,000 fans to a game on a Tuesday night in mid July because they were 15 games out of first. They would show so much enthusiasm that it was making opposing teams angry. They would celebrate every little victory in a game, even though they might lose the game. They took much heat over signing hand gestures back to the dugout when getting a big hit or stealing a base. They still do them!
Through all of these acts of showmanship, they were demonstrating and building a belief in themselves as players and the organization. They were playing with enthusiasm for their job, team, city, and fan base that had not been seen before. It paid off as the club set attendance records in 2015. The fans bought into that enthusiasm. The increased winning on the field also helped that cause, but before the wins came they were creating a mindset for success. They were building a foundation, and this my friends, is winning even though you are losing. These are the building blocks to greatness.
How does all of that relate back to being a better leader, team member, partner, or employee? It is up to you to find it in yourself to show unbridled enthusiasm about what you are doing. You must outwork your competition. You must have more focus and better execution. It is your choice to believe that you will achieve in whatever you are doing. Even when you fall, you must get back up again, because each step forward is a win, even if you get knocked back a few times along the way. You too can be like the 2015 Kansas City Royals and have the greatest success in your business or chosen profession, but first you must commit on the deepest of levels to being a success even before being a success. Most importantly, celebrate every single step towards your goal, and don’t take any of them for granted.
The subject of motivation came up several years ago in reference to some employee turnover as well as increasing salary costs for IT professionals. What truly motivates us as individuals and teams to accomplish goals beyond carrots and sticks? If you aren’t familiar with the term carrots and sticks, it refers to the idea of providing rewards for results, carrots, or punishment for lack of results, sticks.
In reference to the workplace, at some point it cannot just be about dollars and cents. If this were the case, as employees, we would continually move from place to place accepting offers from the highest bidder and never care about the work we were doing. Some people make a career out of this I suppose, but I am not one of those types. I’ve been at my place of work for 15 years and while every day isn’t always roses, I have enjoyed my time there and have never really given much consideration to leaving, ever.
What are the things that add intrinsic value and not just compensational value to a person like myself? I know in my own case, I have turned down many opportunities over the years. I have been offered total package compensation as much as three to four times what I was making at the time. Was I a fool for letting that go or are there aspects about my job that are worth more to me than money? How do I convince or recruit other like-minded individuals so we get long term employees and work towards a common goal without having to stop and restart as people come and go?
I have a long commute in the morning, so I opted for the audiobook. Either way, it’s a short read or listen and can be digested in just a few days. The book itself is only 288 pages and many are filled with worksheets and other tools for analysis. I can’t say I agree with every word that streams from Daniel H. Pink, but I do think his core ideas are solid in their foundation. As someone who has found intrinsic value in my place of work, I was able to look at my own situation and see what made me happy in my career and try and work with the company I work for to help others feel those same things.
Daniel H. Pink also did a TED Talk on the topic of motivation and if you really want to be entertained, the RSA did a cartoon animation of the talk. I highly recommend at least listening to the TED Talk or watching the video. The ideas of giving employees the ability to have autonomy, the ability to have mastery over their skills and a sense of purpose in their career are intrinsic values which, as long as the employee is compensated well with their peers, creating an environment where they can flourish will reward an organization well. Daniel H. Pink mentions in both the book and the TED Talk about the software company, Atlassian, and the idea of FedEx Friday’s as well as the open source movement as examples of getting value back without a carrot or a stick.
Once I digested the information, it was time for action. How do we turn a workplace into a place where others feel the same levels of autonomy, mastery and purpose that I have felt. This is a lot harder question to answer than it is to ask. We started with efforts around the office like free soda and lunches or company outings. We switched to agile methodologies for the entire IT department. We had been operating in small, dedicated teams, so we tried one big team. We then tried smaller teams once again. We tried giving ownership of design, or ownership of process. We even tried the FedEx Friday idea. We changed the structure of teams and how they functioned over and over. There were small improvements, but nothing terribly lasting or exciting.
At some point it dawned on me that in order to have those things, we needed to retain the right people and hire the right people to make it happen. We needed folks that weren’t just here to do a day’s work and go home. We needed people who had what I referred to at the time as entrepreneurial spirit. These are people who are invested and have the spirit of innovation and risk-taking that all great entrepreneurs share. At this point I realized that I was not just an employee of a company, but rather the CEO of my own personal company and that is how my role had formed inside of the organization. We needed people that, while they may not see it in themselves, we saw that they were the CEO of their own self. This is the magic straw that mixes the Daniel H. Pink drink.
If you give someone autonomy who doesn’t have the right spirit, they become scared that they aren’t doing their job well. They become lost without direction. They are constantly looking over their shoulder and wondering if they are doing the right thing. They don’t know how to be a self starter. That same person doesn’t have the burning desire to master their skills. They might try an online course or a night class, but it’s money and time wasted. The content will go in one ear and out the other, because they don’t really want to learn it. They have no desire to become a master. That same person will feel lost and without purpose, and finally, that person will quit and go work somewhere else. I know this sounds very harsh, but it is the reality of the importance of finding the right mix of individuals to work together towards a common goal. Daniel H. Pink was right in his attributes of where motivation comes from, but he was definitely missing one important element. This is the root of the why.
Simon Sinek had a great TED Talk called Start With Why which talked about this very topic. I enjoyed his talk, however, I’d be lying if I said I bought into his entire talk, but I do agree with his core message. The why is just as important as the what, if not more important. Like I said before, this is the missing driver in making the motivation operating system work in the first place. You must recruit the best talent that also is wired with the burning desire to be motivated in the first place. I cannot make you motivated. This is something that exists within you. As a leader, it is my job to give you the tools to become a master, the reasoning or the why to give you purpose, and freedom or autonomy to do your job to the best of your ability and then it is my job to get out of the way and let you do your thing. If you fail or succeed, you did it on your terms, and this is ultimately what is best for the organization as a whole. If I did my part in recruiting the right people, we will all work together in accomplishing the goals we set out to do without having to use carrots and sticks to drive results .
I’ve written before about keeping things simple in software design. One such way to do this that I preach nearly daily is to give things a singular purpose. The moment you introduce multiple purposes is the moment you introduce complexity and most likely the need for a refactoring session in the very near future.
When I started professionally in software, our budget wasn’t large. Mostly, I had to figure things out on my own. I can recall a function we introduced called Search. At first, this function took about four parameters and returned a single output type, but after several software revisions the function took about twenty parameters and could return several different output types depending on an output parameter that told the developer which form was being returned. Why strongly type output? That’s too easy. As you can imagine, this was where the idea of singular purpose started to make sense to me. Making my programs call a SearchThis function or a SearchThat function rather than all programs calling a single Search function.
How do we achieve singular purpose in design? This question can start a great session of paralysis by analysis if you let it. Most programming I do nowadays is object oriented, but this principle applies to any programming style or framework. Singular purpose starts at the application level, then goes to the class level, then to the method level, and even in the variables you declare and how you name them. It exists throughout the design.
SOA (Service Oriented Architecture) was our first attempt, organizationally, to bring singular purpose to the forefront of our designs from the ground up. This was a new way to think about programming, and building applications that provide single services and building a pipeline of navigation through the single service apps to solve a problem. This paradigm changed the way we build applications. In fact, most of our application design today follows the SOA pattern.
We started by chaining Windows services together with MSMQ (Microsoft Message Queue) and pushing a state object through different services that performed actions and appended data to our state object. We have experimented with other queues such as RabbitMQ and we have added caching servers into play such as Redis. We have even migrated these services to the cloud and used both AWS and Microsoft Azure native services to help drive these systems.
SOA is not the silver bullet when it comes to singular purpose. An example from our experience was that we wanted to build a pipeline that was only dependent on the database at the beginning and end of the journey. At some point in the build, one of the developers realized we needed to append information to our state object that came from the database from other processes that kicked off after the state object started on the pipeline. Rather than change when the pipeline started, we eventually caved, and added a service to append the necessary fields of information. This was still keeping with singular purpose, so no harm, no foul. However, because of code reuse, and maybe some impatience by some of the development staff, the database code that was added to a single service was also added to a second service, and then a third. At this point, I was no longer running this group, but from afar it became clear to me that singular purpose and SOA aren’t necessarily equal. The team was still following SOA, but they introduced complexity by having services that did one function and appended information from a database, as well as logged information to a database.
The lesson learned from the above story is that singular purpose has to be as important in your architecture as the problem you are solving. As I mentioned before, if not, you will be in for refactoring sessions sooner rather than later. The team that introduced the database into the several steps in our SOA design, also had to refactor the database out of the equation. They were contaminating their data from all directions and had to only pick specific points in which to allow new data into the model. This was the original design, and the correct solution to the problem at hand. Because we did not account for all scenarios up front, it became the easy way out to add a function to a single service rather than add a single service to the pipeline. It took a while for me to understand why, but I think I have figured it out. We need a system for SOA that makes it just as easy to add a service to the pipeline as it is to introduce a function to a service.
Recently, I have discovered Microsoft Azure WebJobs. I am so new to working with them, I can’t say they are the silver bullet to both SOA and singular purpose, but in my small experience with them, things are looking promising. Expect an entire blog post dedicated to them very soon, but look them up. They provide a framework to do very singular purposed design by exposing just a single function and allowing it to be called on a schedule or have it run continuously and even be triggered by events like messages in queues or files being uploaded. Very cool stuff! I am currently building my first SOA style system with them and I will provide a complete review very soon. The best part about them, is that they run in the space you have dedicated to an App Service in Azure, which is where you run your websites. These jobs can run either across the farm for your site, or as a singleton.
Singular purpose in software architecture is a key component to simple software design. It has to be as important as the problem you are solving to build long lasting, scalable, maintainable software systems. SOA is a good pattern to help reinforce singular purpose, but it is still up to you, as the developer, to make sure singular purpose is at the forefront of your thoughts and your actions. There are many tools, services, and frameworks available to help you in your quest for singular purpose. I am encouraged by WebJobs and I will provide an update as to my thoughts on them in the near future. Ultimately, it is on your shoulders to build specific apps, classes, and methods that tell a single story, rather than every story that needs to be told. When we launched the Search method with twenty parameters, we found many years of headaches maintaining a poorly designed function that found itself interwoven into much of our infrastructure instead of the many hours or days of pain it would have been to refactor it out, or even better yet, the hours of contemplation about keeping things simple that could have saved us that complexity in the first place. Learn from this and happy coding! 🙂
When writing software, one of the things I preach to developers is to keep things simple. As engineers and architects we sometimes turn off our common sense in favor of trying to solve all business problems at once. We forget that the first problem we have to solve is the one at hand and not the rest of this project, next project, the bugs from those projects that could arise and the thing that might be cool or catastrophic if we go down some road in three years.
An example might be that a client asks for a modification to an existing form measuring satisfaction. Your client wants to capture a checkbox of whether the person submitting the form wants to be contacted in the future. The checkbox being checked means they do want to be contacted and unchecked means they do not.
In this moment, it’s best to go back to what was originally requested. Add a checkbox to a form. That’s it. Keep it simple. Start with simple.
Our job is challenging. We have to understand the best way to deliver value and yet not under or over deliver. Take the example of the checkbox, what if the client did want more from the checkbox and didn’t know to ask? It is also our job to ask the right questions. Often, our clients know only a narrow view of what they want because they don’t understand what is possible or don’t understand the scenarios that can occur from the development they are requesting. It is our job to keep ourselves in check to keep it simple as well as keep our clients on the path they truly want to go down.
We are not tasked with an easy job, but when we truly focus on keeping it simple and delivering value we will keep projects running smoothly and delivering bang for our client’s buck. Remember to start with simple, ask the right questions, and deliver time and time again.
Failure is an opportunity to intelligently begin again
This is one of the principles I have built my career on. I’m certain that I have failed and lived tell about it many more times than I have celebrated sweet success.
First, it’s important to recognize that failure is okay as long as you learn something from it. Failing without learning is like paying for dinner at a fine restaurant and sending your plate back to the kitchen without eating. It’s expensive, and you miss out on the good stuff. The truth is that failing at anything can teach you lessons you just can’t get in any other way.
There is a mantra in start up companies to fail fast and fail often. This iterative idea is prevalent in business today. Agile methodology reinforces this concept and it has proven, that when applied correctly, it will get a business not only from point A to point B faster, but often point B is not the original point B envisioned, but an exponentially better one. Gradual iterations provide for more opportunities to fail and therefore more opportunities to learn, solve new problems, confirm or deny assumptions, and improve.
I have always encouraged my employees to try things and see if they work. I teach them to embrace failure and avoid paralysis by analysis. They should not fear the unknown, but rather be excited to the possibilities that lie ahead. These concepts are not in our nature as human beings. We have primal instincts to survive and we are in conflict with this by embracing failure.
Learning from failure is such a powerful tool for us in IT. We have such a unique landscape of tools and technologies. We build and can rebuild using Agile principles and be more agile and swift than other industries. It is imperative we indeed fail, learn from failure and repeat until we get a desired outcome. I promise, if you focus on this moment in time, this single problem, and actually learn as you go, the end result will be better than you could have ever imagined in the first place.
I started out my career as a software developer, but well before that I learned some valuable lessons about what it would take to build a career in computers.
When I was 10 years old my grandmother passed away. She didn’t have a lot of money, but she loved her grandson enough to leave him two gifts. First, she left enough money for me to get to go to Disney World, because all kids should get to experience that place. Second, she left me the money to get a home computer. At that time, in the 1980’s, home computing wasn’t that common, but becoming more and more common every day.
My first computer was an Epson Equity I+ with a 5.25″ floppy disk drive, an EGA monitor, and a Panasonic dot matrix printer. I am still kicking myself for throwing it out. I have fond memories of my time learning on that computer.
When we got the computer unboxed and setup in a spare bedroom at our house, I remember the anticipation of what I would see. My computing experience before this was a TI-99 that my cousins and I got one year in the early 80’s that I promptly disassembled, the Atari 2600 that a friend had and the Nintendo Entertainment System that I schooled everyone on as a kid. Maybe I didn’t really school everyone on the NES, but let me have my moment. Back to my first boot. After hitting the power button, I was expecting some graphics, music, a game perhaps. What did I see? I saw the screen flip numbers up to say 640K of RAM and then some grinding sounds and a chirp, then finally a blinking cursor at a C:\ prompt. I didn’t know what that meant, but I knew I had work to do.
Along with my home computing system were three fat books on spiral binders. The first was how to hook up the actual hardware and information about the hardware itself. I threw that to the side, because we fumbled through that already. The second was a book about MS DOS 3.0. I thought to myself, “This might come in handy,” and set it in front of me. Finally, there was a book on programming my new computer with GW BASIC. I thought something to the effect of, “This is it! I can actually build video games!”
I spent the next four years or so hammering away at that computer. As friends got 286, 386 and 486 computers. I still had fun making things work on my 8088 processor architecture. I built scripts to make home computing easier, and to display boot menus and such. I tinkered with simple game design. I taught the computer to make noises, play sounds and even stumble through some bad computer beep music. I built ASCII character graphics into art and learned a drawing library that taught me how to draw circles, squares, rectangles, lines and more in all 64 colors my EGA monitor could display. I built routines to print amazing HAPPY BIRTHDAY banners in many varieties of fonts, including some homegrown fonts. I acquired a modem and made my computer talk over the telephone line to my cousin’s computer just because the anticipation of waiting on the response to “Hello” was so darn thrilling. I remember getting a mouse and installing the drivers and building my first program that could accept a click.
My first computer taught me the most important lesson in my career. It isn’t the hardware you have or don’t have. It isn’t the computer programming language you choose. It isn’t the skills you possess now or the mountains of practice and research to possess new ones. Computing is simply about a can-do attitude and a relentless desire to solve the problem at hand.
As IT professionals, we are tasked with making the impossible become possible. We are tasked with building something that has never been built before. This is often on a budget and equipment and tools that are lacking in more ways than the blinking C:\ prompt I saw when I booted my first PC.
When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
Any sufficiently advanced technology is indistinguishable from magic.
I agree, especially with the last one. I think the way I describe it is that as an IT professional it is our job and our privilege to turn fantasy into reality, fiction to fact, nothing to something, and solve problems with unbounded enthusiasm and reckless abandon.