Software development estimates are often a major point of contention and misunderstanding. These problems are almost always rooted in participants having different language, expectations, and assumptions about the process. How many times have you seen something like the following?
Stakeholder: “When will that feature be done?”
Developer: “What do you mean? I finished that code last week.”
Developer: “Oh, well it’s not deployed yet so you’ll need to wait until that happens before you tell them they can use it”.
There are multiple communication problems evident in this example, capped by the fact that neither party has the same idea of what it means for a feature to be “done”. It’s not that either party has the wrong definition, they just haven’t communicated well enough to understand each other.
I’ve been intrigued over the years watching various machine learning techniques steadily progress. Unsurprisingly, some of the advancements that are most apparent are around artificial image generation.
For a long time, Google and others would release videos and blog posts showing what they were working on, and us mere mortals would watch in awe from a distance. Then DALL-E came along with a public beta, and the general public got an accessible tool for anyone able to pay the reasonable fees associated. Since it can take several tries to generate the image you are looking for with these systems, it’s definitely not a cost-free system to use.
The next iteration in machine-generated imagery is here now, arriving as Stable Diffusion by Hugging Face (https://huggingface.co/blog/stable_diffusion). This is a pre-built, freely available model where all the hard and expensive work of training is done. Anybody with a modern, gaming-ready graphics card who is comfortable running a few commands in the terminal can get it up and running.
As tends to happen with useful open software, a community has already cropped up around this tool. The community has made Stable Diffusion easier to use, and has adapted it to multiple hardware platforms. Support was recently added for the Apple M1 chip and its integrated GPU, so I had to give it a try.
My verdict after 2 days of using it: I can’t remember the last time I have had this much fun!
A desire for control is a core human trait. We all want to have control over our environment, control over what happens to us in our day-to-day, and control over our future.
We want relationships that we can influence for the better. We dream about a financial state where we can choose what we want to do with our time and money. We build personal routines that bring us fulfillment.
Autonomy has repeatedly been shown to be one of the single biggest drivers of professional satisfaction. We exert a lot of effort to affect who we work with, what we work on, and our prospects for upward mobility and professional development.
Full stack developers are highly sought after in the software engineering world, for good reason. Being able to build a user-facing application while simultaneously keeping APIs, business logic, and databases working together is a valuable and hard to find set of skills.
Equally valuable is the full stack designer. You may not have met one or even heard of them, but they exist and they bring tremendous value to an organization.
A full stack engineer is as comfortable writing a complex SQL query as they are using the Chrome debugger, and a full stack designer knows how to architect the ideal user experience and go beyond the mockup to implement it as an actual user interface.
Choosing a technology can be a difficult, stressful, time-consuming process. It’s easy to find yourself in complete analysis paralysis, spending tons of time and money ensuring that your decision is the correct one.
Let’s say you need to choose a database for your new system. Just about every application ever built uses a database, so no matter what you are building this is hardly untrod territory. That means it should be easy to find somebody who has built an application like yours, right? You just need to read their blog about why they picked the tech, mirror their choice, and voila!
When I worked in the US Department of Defense, our computer systems had password requirements that were the stuff of legend. 3 lowercase letters, 3 uppercase letters, 3 numbers, 4 special characters, and they had to be at least 16 characters long. Plus they had to change every 30 days, and couldn’t be one of the last 25 passwords used. Because these were the requirements for our primary system logins, there was no chance of using a password manager.
So how did people handle this? Everyone diligently memorized the new password every thirty days, thankful that there were policies keeping everything secure, right?
Of course not!
Everybody kept their password on a sticky note stuck to their monitor where it could be viewed by anybody walking past. And the technical people who understood the risks of their password getting compromised? Well, they took a more sophisticated approach like tucking the sticky note in a desk drawer where it would take at least 30 seconds for someone else to find.
The James Webb Space Telescope (JWST) famously has 344 single points of failure – meaning that there are 344 individual things that could go wrong, any one of which would render the entire $9.7 billion space telescope a failure.
Building a piece of equipment like the JWST is pretty different from building businesses or software systems. Learning about how the space telescope was built and operated made me think a lot about resiliency though, and whether there is anything that a typical business can learn from NASA’s approach.
When you talk to business people or engineers about resiliency, they usually focus on achieving that resiliency through redundancy. If we can build this incredible space telescope without having each part be fully redundant, is there anything that can be applied in our approach to resiliency with the software and business systems we build and manage?
I’m excited to announce that I’m part of Corso, a company dedicated to providing high-impact solutions to e-commerce merchants and their customers. Our immediate focus is to provide a service that solves problems with packages that become lost, stolen, or damaged during the shipping process, and to improve the environmental impact of orders being fulfilled into the hands of their customers.
My new adventure represents a big change for me since this is my first time working in the fast-paced world of e-commerce. I’ve enjoyed building and managing high-performance customer service teams in the past, and I’ve spent considerable time designing and implementing industry-leading technical solutions for those teams. Although e-commerce is new for me, the focus on providing an excellent customer experience through better technology solutions remains the same.
There are a lot of different reasons why I am excited about this opportunity. In no particular order, I wanted to share with you some of the things I look forward to doing:
The concept of 5 whys is frequently trotted out as a formula for root cause analysis. Its proponents claim, “Just ask ‘why’ 5 times, and you will fully understand the root cause to a problem you are having!” The same concept is frequently applied to the process of researching and planning new solutions that your business can offer the market.
In case you aren’t familiar with the approach, the idea is to dig into surface-level problems to make sure actually understand the root causes. Asking “why?” 5 times as you dig deeper for each is the core of the method. Suppose our revenue is down 10% for the quarter:
Why? -> Because we lost 10% of our customers
Why? -> Because our customer service level suffered
Why? -> Because we don’t have enough people to answer the phone quickly
Why? -> Because our customer service agents are leaving for other opportunities
Why? -> Because our pay and benefits aren’t attractive enough
While it is important to dig into root causes, anybody who has spent time with small children knows two things about asking questions like this: 1) there can be a lot more than 5 layers of “why?” underneath any given question, and 2) the answers sometimes stop being useful long before you run out of questions to ask.
I love the Agile Manifesto. Go ahead and visit agilemanifesto.org, bask in its turn-of-the-Millenium aesthetic, and read it again. (If you are involved in software development, you have read it before, right?) It will take 60 seconds at most, and I’ll be here when you return.
Back? Good. I recommend visiting the site frequently, it’s helpful to periodically be reminded of its principles.
Few things have resonated with me quite as strongly as the manifesto, and given its impact on the software industry, I am apparently not the only one who has experienced this. There are very few companies out there who don’t make a huge effort to proclaim themselves as Agile.
The problem is, few companies actually prioritize the principles of the Agile Manifesto, despite their claims.