Fit for Sale

Sales

As an app developer, I am often approached by friends and acquaintances with “great” app ideas. They believe their idea is worth millions and that I should drop everything and develop their app. Businesses too fall prey to the idea that “I need an app“. Either way, it’s imperative that adequate market research be performed prior to developing any piece of software. 

A Great Idea

A few years ago, I was approached by an individual who had a “great idea” for a software application that was going to revolutionize the industry. He had some startup money to develop the application, and was in a hurry to get started. He contacted me to write him a mobile application, cloud-based management system, and REST services for integration points. It was an ambitious project for the client, and I was excited to start developing. He provided the requirements to me, and I wrote the software. I provided feedback to improve the application, but it was ultimately the customer’s decision what he wanted to include or not include.

Poor Market Research

Unfortunately, as the project moved forward, I learned that the client had very little money for development. None-the-less, we worked to create a working product which we achieved on his budget. But, as he would learn during the next month, he was creating an application that nobody actually wanted. Not only did his application lack features that would be necessary for adoption, it served only a very small niche market. The customer assumed he knew what people wanted, and had never bothered to reach out to any prospective clients for feedback.

Consequences

Due to the customer’s poor market research, he was unable to find clients interested in his software application. Months went by with very few interested parties, and nobody ultimately purchased the software service. Consequently, the customer blamed me for writing an application that nobody wanted. He even fought me on payment because he was unable to make his money back through sales.

Lessons Learned

There are several important lessons to be learned from this experience. First, if you’re paying someone to write you software or create any other work for you, make sure it’s worth the cost. It’s your job as the customer to know what you are purchasing and to ensure that it will meet your business objectives. As a software consulting firm, I can provide you with information and develop software. However, I can’t tell you wether or not your application will be a success. Second, market research is of paramount importance for any project. If you don’t know the target market, the demographics, the estimated number of consumers, and other key data; you can’t determine financial viability of the project. Before you go into any project, do your part first and ensure that the work you are paying for will take you where you’re trying to go!

Classic Hacking

Security

I’ve been involved with technology since the mid 90’s. During the late 90’s, I worked on Unix systems. It was those experiences that lead me to love Linux, taught me to program in C, and helped me learn to automate tasks using various scripting languages. But the 90’s were a much different time for security. Nobody really worried much about hackers or social engineering. And now, over 20 years later, I see people in the workforce that have been robbed of some of the fun I had in the past due to increased security on machines. Of course, increased security is good, I’m not going to argue otherwise. But it has also made a lot of the ‘fun’ from the past no longer possible.

Remote Display

When I was working on old Unix systems, one of my favorite hacks was to set my display to another computer. Since Unix display works as a client/server model, you can actually set your app to appear on any computer monitor you want. So, it was common where I worked to find the most horrible graphic you could and display it on someone else’s machine. Always a good laugh. Other tricks would allow you to play audio on their speakers (great when the individual has fallen asleep at their desk) or turn their keyboard buttons on and off.

Password Files

Long before the /etc/shadow file, passwords were stored in the /etc/password file. And, since the file was readable by anyone, you could easily grab the entire password list and run it through a tool like John the Ripper. Even more fun, commands like ‘ypcat’ would allow you to get the passwords of all users on the network even if they weren’t on the local machine.

Email Overflow

My sister’s first experience with the internet was through a device called “WebTV”. This device was a small terminal that would turn your TV into an internet terminal. It was a cheap, easy alternative to a computer. It also suffered from a pretty simple flaw – you could only have a limited number of emails. (200, I believe.) I found an unsecured email relay – pretty common in the 90’s – and spammed my sister with enough messages to flush out all her email. As you might guess, she was mad.

A New World

How things have changed. Unsecured email servers are much more difficult to find, and Unix is now much harder to hack out-of-the-box. While most of the hacks of twenty years ago were mischievous in nature, today’s hackers are far more sinister. And, thankfully, the world has adapted to become a safer place. Nonetheless, I still look back to the simpler days of computing and the fun we had.

Payment Terms

Money

Recently, a fellow small business owner asked me how I handle billing. For a small business, money is often one of the biggest concerns. Without a steady flow of cash, you can’t meet your business objectives or your personal financial requirements. As a small business, you have to determine when to bill and how to bill. Even worse, you have to define how you deal with delinquent payments – which can kill your business.

When To Start Billing?

The first question to answer is when do you start billing? This is particularly true if you’re billing by the hour. Does the clock start ticking at your first meeting? After the project requirements are defined? After the project is complete? For my business, anything after the initial project meeting is billed to the customer. I think it’s important for a customer to understand that project planning, requirements gathering, and any other tasks completed before any actual code is developed is an integral part of the development lifecycle. I typically bill the first of the month after any billable hours have accrued. I’ve found that the longer you wait, the more the bill increases. Then, you risk the customer suffering from sticker shock when you finally send the bill after months of work.

Late Payments?

When I started my business, I was so pleased to have customers that I didn’t worry about late payments. I assumed that my customers respected me enough to pay me on time. I was incredibly wrong. What I’ve found instead is that many companies will put me at the bottom of the list of payees. Why is that? Well, I think it’s pretty simple. The customer knows they have to pay their lease on time or risk eviction. They know when they fail to pay their internet bill, they won’t be able to perform their mission. What happens when they don’t pay you? Likely nothing. Additionally, they know you don’t have a collections branch and are unlikely to use a collections agent. Thus, they have absolutely no reason to worry about when they pay you. I have learned to include verbiage in my contracts defining payment terms. I give customers a 5 day grace period, and after that the customer is charged a late fee. Additionally, all the customer’s projects are paused until payment is received. If you continue to work, you end up months behind on payment and continuing to work for free.

What About Equity?

I’ve had many ‘customers’ offer to pay me in equity. I do the work and they will give me a percentage of the revenue generated by the software. I have a very simple answer for this kind of relationship. No. While an individual may think that their idea will generate millions, they rarely do. Even worse, you’ve now wasted time developing software that you will never be paid for. The original ‘customer’ lost nothing. You lost countless billable hours to a project that will never be profitable.

Conclusion

Money is the lifeblood of any business. What I’ve learned is that it’s imperative to have clearly defined payment terms and procedures for your business. When you fail to make those terms clear to customers, you will quickly find that your business struggles to get by and that you are spending more time nagging customers to pay than you do performing your business’s objectives.

Surface Pro 6

As a developer, I tend to need a lot of hard drive space for projects and tools. As such, my MacBook Pro was starting to run out of drive space. This was only exacerbated by the fact that I was also running Windows 10 on the same machine for .NET projects. I decided it was time to replace my MacBook Pro, and looked at the newest product line. Unfortunately, I was very disappointed by the lack of ports on the new MacBook Pro. With a sticker price of nearly $4,000 for a machine with all the bells and whistles, the lack of ports is simply unacceptable.

What to Do?

After much deliberation, I decided to get a separate Windows machine and reclaim the space on my MacBook Pro for MacOS. I had been looking at the Surface Pro for a while as it looks like a great machine. So I went to the store and purchased the computer, a keyboard, and the pen for around $1000. Given a price tag one fourth that of a new MacBook Pro, how does it compare? So far, I am very impressed. The Surface Pro includes numerous features that the MacBook Pro can’t touch including: facial recognition for login, touch screen, functionality as both a tablet and a laptop, and he use of an optional pen for drawing.

Conclusion

While the Surface Pro does not compete with a top-of-the-line MacBook Pro in terms of raw horsepower, it is lightweight, multipurpose, and more than adequate for the occasional .NET project I need to support. Even more exciting, it will work far better than my MacBook Pro for taking onsite to gather customer requirements or take quick notes.

Note to Apple

Apple, your decision to remove standard USB from your laptop cost you $4,000 I would have gladly paid. Instead, I paid $1,000 to buy a laptop from your competitor. While you may think you’re a trendsetter, a large number of developers I’ve spoken with are less excited by your choice. For us, computers are a tool to solve a problem – not a trendy accessory. You managed to capture a growing portion of developers, but focusing on trends instead of solutions will negatively impact that growth in the future.

MacBook Pro?

I’ve been a Mac user for several years now. I have a MacBook Pro (2015) and a MacBook Air. I love them both. They are amazing machines. From battery live to performance and every aspect in between, Mac laptops are awesome. What makes the MacBook Pro so great for me is how well it’s positioned as a development machine. Lots of ram, high-quality graphics, fast, Linux compatible backend (BSD), and ports for everything I need. When I visit a client who wants to see what I’ve been working on, I connect a HDMI cable to my MacBook Pro and walk through the progress. If a customer asks me to add new photos to their website, I insert their SD card into my computer and grab the images. When I want to connect with a peripheral – such as a barcode scanner or a mouse – I use my USB. If I am working with Arduino, MicroBit, or a PyBoard, I connect a standard MicroUSB cable to my machine.

Time To Upgrade!

Now, after years on my current MacBook Pro, it’s time to upgrade. I need more hard drive space for all my projects, and I’d like more memory for using virtual machines. Of course, I want another MacBook Pro. Unfortunately the new machines seem far less developer friendly. Why? Because they ONLY have USB-C ports. No HDMI, no headphone jack, no Thunderbolt, no USB-A, no SD Card reader. If I want any of the above, I need to by a converter to connect to my USB-C port. So, when I go onsite, I will now need a laptop and a bag of spare cables to connect to what I need to use. What a horrible user experience! As a laptop user, my objective is to carry around as little as possible. Apple, why did you do this? Why did you destroy a machine that was excellent for development by removing all the ports that made it so useful?

What to Do?

I’ve been pondering for the last few weeks what to do. Do I buy the MacBook Pro along with all necessary accessories to achieve what I need, or do I buy a Windows laptop (for half the cost) that already contains all the things I want? Unfortunately, I like MacOS (specifically the command prompt and dev tools) too much to go back to Windows. So, I’m stuck paying top dollar for a machine that is severely lacking in its ability to perform many of the very things I buy a laptop to do.

Agile Pricing?

Today, agile software development is the standard project management model. In many ways, it’s an excellent model. It allows for rapid changes to meet business needs, helps ensure quality throughout the process, and ensures that stakeholders have maximum visibility. But there’s one big problem…

How Do You Price Agile Projects?

Since Agile projects requirements are continually refined during the project, how do we know the amount of work to be done? How can we define a timeframe for development if we don’t have a clear picture of requirements? How can I tell you the cost when I don’t even know exactly what you want to do? Certainly I can provide an estimate based on the high-level definition of the project. But agile makes scope creep easy. New requirements can be added or old requirements removed. This means my best estimate may be wildly inaccurate.

How Can Developers Learn to Estimate Projects?

Making things more difficult, developers who have only ever worked in an agile environment will have difficulty estimating project workload. Why? Because they have never had to. Agile is so focused on the now that no attention is ever paid to the larger work of the project.

Future of Agile

The more agile work I do, the more I have mixed feelings about the process. While it allows greater management input throughout development, it suffers from a variety of problems. Sometimes, I even refer to it as (Fr)agile Development. This is just another issue to add to the list. My hope is that the software industry finds a better way to manage development that solves the problems with Agile while still providing all the positive aspects.

Social Media Etiquette

Social Media

Today, social media is increasingly being used as a tool for marketing and advertising. However, if done poorly, you run the risk of tarnishing your brand and being viewed as a spammer. Here are a few simple etiquette rules for social media.

Avoid Follow/Unfollow

Today, I was notified that I had a new follower on Instagram. After seeing that it was a local business, I decided to follow back. Trying to develop relationships with local businesses is an important aspect of my social media efforts. It wasn’t until a few hours later that I had an opportunity to visit their Instagram page. But when I did, I noticed that they had already unfollowed me. They had no actual interest in my content or in developing a relationship – they simply wanted to show me their products. This isn’t much different from spamming and does not present a positive view of your organization.

Create Content Not Advertisements

People are unlikely to follow you on social media to see what you have on sale this week. People want to see your personality, what your business stands for, and who you are. Of course, all businesses will occasionally create content that advertises their goods and services, but if that’s all you do, expect to be unfollowed. Social media is for growing communities – not a new tool to spam me with ads.

Stop Nagging Me About Services

On LinkedIn, in particular, this is common. Someone friends you and – wanting to grow your own circle of connections – you accept. Then, you get a private message about the services they offer. Viewing it for what it is – spam – you ignore the message. A week later, another message. Then a month later, a message asking if you got the previous message. Yes, I got them all. I chose to ignore them because I wasn’t interested in your product at this time. Additionally, I now am distrustful of you as I see you too are a spammer.

Like/Know/Trust

Want to develop your social media the right way? Use the like/know/trust model. First, users like you. They see your posts, enjoy your photos, laugh at your jokes. After a while, users feel that they know you. The’ve seen your stuff, they know what you stand for, and they feel that they understand you and your company. Finally, users trust you. They have seen you in action and know you’re knot a spammer. They recognize that you provide valuable content they want. They know you’re someone they could reach out to if they need your services. That’s the formula for success. You develop community and relationships, and people see you as a valuable asset instead of a spammer.

Do Unto Others

The golden rule applies to social media just as it does anywhere else. When you’re engaging in social media efforts, ask yourself how you would view another business if they used the same tactics. If it’s not favorable, don’t do it.

A Programmer’s Purpose

Today, it’s becoming increasingly popular for programers to be ‘opinionated’. In the software world, to be ‘opinionated’ means to believe your way is the right way. Other ways are wrong, and your way is right. There’s nothing wrong with having a preference, but the truth is that there is little room for opinion in software engineering. Software projects need to meet requirements such as budget, programmers available for maintenance, stability, etc. Championing a new language or framework may be fun, but when you leave, are there other developers available to support the project? Even if your preferred framework is better, it’s of no concern to a client when the language dies for lack of users and they have to pay to have the application rewritten.

A computer science student I know is all about Julia. Honestly, I’ve never met a single Julia developer or even seen a line of code in that language. On the list of popular languages, it’s not even a blip on the radar. However, this student insists that Julia is the way of the future. I’m not sure where he’s hoping to find work, but it won’t be in the local area. I remember the same thing when Scala came out. Every video I saw spent half their time attacking Java development. As above, I know absolutely no projects written Scala nor do I know any local companies either using it or planning to.

How should we select frameworks and languages?

The answer is actually pretty simple. Commercial software development has one purpose – to support some business use case. As such, frameworks must be chosen to support commercial business. What things make a language or framework commercially viable? It should be stable, have tools available to support commercial usage, and be widely used such that new developers can easily be found in the future. Additionally, it should have adequate resources available to help when you get stuck.

Commercial application development is no place for experimenting with new frameworks or basing your decision on an opinion about what is better. Find commercially viable frameworks and save yourself the hassle of supporting your new framework that may be dead in a year.  A programmer’s purpose it to write commercially viable software – period.

Apple’s Corporate Problem

Anybody who’s ever worked for any business knows that Windows PCs are the norm. Sure, there are always a few Macs to be found in the marketing department or with people who work with graphics, but the bulk of business computers are PCs. It’s easy to point out reasons why that’s the case. For instance, PCs are substantially cheaper than Macs (although many Mac users would be quick to point out that you get what you pay for). But one of the bigger problems I see is how incredibly business hostile Macs are. Let me give you a some examples of problems I have with one of my clients. Like most organizations, they are predominately Windows. However, they have a few Macs that are used exclusively for multimedia. And they work great – until it’s time to upgrade the OS. You can’t upgrade a Mac without an AppleID. Of course, the customer has no real reason to setup an account with an AppleID, but you have no choice. As several different people use the computer, nobody is going to use their AppleID for the machine and since all users need to share documents, settings, etc, multiple accounts are out of the question. Now, that leaves only one option – creating a bogus AppleID just to upgrade the computer. And, as Apple demands a phone number to setup for Two Step Authentication, some user will need to be the primary point-of-contact for any issues that require authenticating by that AppleID. Not to mention that information must be fabricated for the imaginary user and logged somewhere – including answers to security questions that make no sense in that instance. This is all easy compared to the fun of trying to create a developer account for a business. Not only do you have to go through all the above hassle, you also need to setup an Apple device for Two Factor Authentication. Sending a message to a phone number isn’t enough, you must have an apple device connected to the account. None of this was a big deal until recently – when Apple said that the person responsible for an apps content must have their own AppleID. Previously, someone else – with an AppleID took care of everything. Now, we have to find another Apple device to setup for their 2FA. For a client who is already Mac-shy, this does nothing but confirm their PC bias.

My message to Apple: Find a better way. You may do a great job with individuals, but your policies are a disaster in the business world.

Title Inflation

My first job as a computer programmer was for a small software company. Our tech department consisted of only a handful of people. I functioned as developer, QA, tech support, and network administrator. When I left, we had three programmers. As the person with the most time in the organization, I had the title ‘Senior Developer’. At the time, it sounded great. However, it would be more than a decade before I would have another title suggesting my status as a more senior level engineer.

During the last few months, it has become apparent to me that title inflation has really gotten out of hand. I read an article last week that Javascript Developers want to be called UX Engineers instead. The bulk of programmers are not great at interface design – developers use logic, interface designers use feeling. It’s a left brain/right brain thing, and few people are actually great at both.

Likewise, everyone wants to be a Full Stack Engineer today. Sure, plenty of people can do all parts of a project – from the HTML frontend to the backend and the database. However, very few are actually experts at all of the above. Most Full Stack Engineers are really just jack-of-all-trade sorts who have not mastered any particular part of the process.

I see even more title inflation when I look at small business owners. Everyone is a Founder or CEO – yet few, if any, of them have employees or revenue to command such a lofty title.  Or better yet, people claiming the title Director of some department or another yet having nobody underneath them. You’re only fooling yourself.

What have I learned from all this? Titles are meaningless. What really matters is what a person has accomplished. If you had to prove to someone that your title was appropriate, could you do so? On your resume, can you provide several bullet points to validate your title? If you cannot, you will be disappointed when the next organization you work for gives you a title inline with your actual skills.