Sometimes I hear people generalize that software developers aren’t creative. I’m always quick to correct them. “Are you kidding? The kind of problem solving we have to do takes a very creative mind!”
What they are probably thinking is they don’t think software developers (and other types of engineers) are artistic. In my opinion:
Creative – relating to or involving the imagination or original ideas
Artistic – relating to or characteristic of art or artistry
I tend to agree that computer science majors aren’t known for being especially artsy, but I do know plenty of software developers who do make art of some sort. DelMar employs two people who have made musically professionally, and musicians are artists, right?
One of my favorite ways to show off our creative (and artistic!) abilities is to make graphic designs we use on our swag items. I remember placing our first order for a box of coffee mugs and thinking “What are we going to do with 70 identical mugs?”, but it made me happy to give them away to family, friends, college students, interns, and random people. I felt like Santa! We soon got some Swoosh (Mikel’s awesome, almost famous basketball statistics app) and DelMar t-shirts, and had fun giving those away as well.
A few times each year, we sit around and brainstorm ideas for new graphics we can have printed on the shirts, mugs, stickers, pint glasses, magnets, and even lip balm. (Lip balm? Who gives away company branded lip balm for swag? DelMar does, that’s who!)
If you like anything you see, we’ve got our “merch table” right by our front office door with most of these things. If you come by to visit us, I’m sure you can talk us into giving you some.
There was a thread on the DelMar Slack recently about how GitHub was announcing AI assistant programming. Yesterday I happened on this post by Eric Sink. Erik Sink and Joel Spolsky were the two great bloggers (before it was called blogging) who wrote about software as a business. I used to always read everything they wrote, and often used their essays as reading assignments for my upper-level courses at Purdue. In this latest post, Eric echoes my feelings about the importance of knowing how computers work.
“ … it feels to me like yet another step toward shallow understanding in our field.
In my nearly 4 decades of writing code, I have consistently found that the most valuable thing is to know how things work. Nothing in software development is more effective than the ability to see deeper. To borrow Joel Spolsky's terminology, I claim that almost all abstractions are leakier than you think, so it is valuable to see through them.
… what I'm saying is that after I understand how things work, seeing how to do something is usually trivial.”
I also have spent the past four decades in the software development profession, and I agree completely with Eric.
Whenever I talk to potential clients about DelMar, I always tell them how we can write software to do just about anything. We aren’t limited by a single UI toolkit, OS, programming language, some opinionated BE framework, or a single way to persistent data.
I'm confident making this claim because DelMar has a talented team with varied experiences, we've backed up my claim over and over again, and most importantly, we understand how computers work.
My first job in 1982 was as a Cobol mainframe programmer. Then I wrote software for DOS PCs, then Windows PCs, then Palm Pilots, Blackberries, Pocket PCs, Windows phones, iPhones, Android phones, and the web. Each platform used a different programming language and other development tools. But because I knew the first principles of computer programming, the learning curve for each of these platforms never seemed all that steep to me.
I (and I assume Mr. Sink and Mr. Spolsky) had the advantage of learning computer programming back when there wasn’t all that much to learn. One simple programming language (Cobol) and compiler, one text editor (CANDE), one OS (Burroughs MCP) … that was about it. Oh, and I had to know how to read a hexadecimal memory dump because that was the only debugging tool you had when trying figure out why your program crashed. After one year at my first job, I felt I had learned just about everything there was to know about writing software for that company.
Compare information-based systems from 1982 with modern systems of 2022, and you’ll find the amount of computing layers and developer tools it takes to move data stored on a server to be displayed as pixels on a screen, is staggeringly huge. Today’s developers have to learn dozens, if not hundreds, of technologies for even the simplest systems.
At DelMar, we still believe it’s important for all developers to know how computers work. That’s why when we hold job interviews, I ask questions related to first principles of computer programming, and not so much reviewing what they have on their GitHub or talking about fad technologies. If we love the candidate but we feel they are missing some fundamentals, we’ll hire them anyway and spend the first few months in training them on the essential concepts.
Give Eric's post a quick read: https://ericsink.com/entries/depth.html
And read this one too if you haven't already: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
I was talking with someone just yesterday who told me, “Software is so much easier to create now than ever before.”
This person is not a professional software developer.
What has changed is the number of software application types that can be created. (Cool! I can sit at my desk and use my phone to turn the heat on in my car!) But for developers, building modern software is much harder than ever before because applications are much more complex than ever before.
This increase in applications and complexity is largely caused by the public use of the Internet. Before we networked computers together, there was a lot less for a developer to worry about. A programmer could write software using a single programming language, copy it to a floppy disk or CD ROM, and give the disk to someone. If someone had that disk and an MS DOS or Windows PC, they could run the program. If a user typed in new data, that data was saved on their PC’s disk drive. It was up to the users to keep their PCs secure and the data backed up. Simple.
But now our complex applications require the Internet, and when we require the Internet, we’ve got a slew of new dependencies. And the companies that provide those dependencies all want money.
Here are just a few of the things modern systems now require just because they use the Internet:
First you need an Internet-connected computer to host your system. Easy enough. Just create a virtual server using a hosting service such as Amazon’s AWS or Microsoft’s Azure. There’s a monthly fee, and Amazon and Microsoft will happily rent you as much computing power as you want. How much will it cost? Hard to tell because it depends on how much your application is used.
Now you’ll need a way to uniquely identify that computer to all the other computers. That’s done with a domain name and an IP address. Again, easy enough, but now you need to create an account with GoDaddy or Domain.com and give them your credit card number so they too can bill you.
Sending data through the Internet could cause privacy issues, so you’ll want to encrypt your data as it flows through the pipes. Encryption used to be used only in special cases (e.g. passwords and credit card numbers), but now we encrypt everything just to be safe. So you create another account with another company and give them some money for a digital certificate file to put on your virtual server so the other computers on the Internet know your computer is legit.
Your system will probably need to save data of some sort. And this data isn’t for just one person. Because the system is running on a single virtual computer on the Internet, that one computer has to save the data for everyone using your system. That much data is best handled with an enterprise-scale database management system from one of many vendors. Sometimes data storage is free if your needs are small, but when your data storage needs get big, you pay for both the database engine and the space to store the data.
Applications that run on web browsers are available to anyone who knows the URL, which is public. You most likely will want only authorized people using your application. So now you pay your application developers even more to create ways for users to register for accounts, sign in, sign out, etc. Maybe you'll even pay to build in permissions so different users can perform different tasks. Oh, and the users might be in different time zones, or maybe some are in the US and others use the metric system for measurements. You’ll need to pay for additional coding so the user interface will display information suitable for wherever the user is.
What if a user forgets their password? Let’s send them an email with a link to reset it. It used to be simple for a server to send an email using SMTP, but spammers made email less reliable. So now the best way for an application to send an email is to use a third-party email company like Sendgrid or Sendinblue. Like everything else, just create an account with the email provider, give them your credit card number, and pay the developers to build in this forgotten password feature.
Email not dependable enough? Maybe you should give your users an option of receiving messages via SMS instead. Plan on using (and paying for) a third-party SMS service like Twilio.
Want your users to pay to use your application? Sure, we can do that. Just create an account with a credit card processing company like Stripe, and pay the developers to code in hooks to that system. Do the credit card companies charge to use their services? Don't be silly. Of course they do.
Software is never perfect. Code will often encounter something unexpected – an exception. You’ll need a way to log these exceptions so your tech support and software developers can research and prevent them from happening in the future. How is this done? Well, you just pay to use another third-party service that specializes in catching and logging exceptions. Some are free. Some charge a fee. All require you to create another account to manage your stuff.
If you connect your computer to the Internet, malicious hackers from anywhere in the world can attack it. Maybe the hackers will get administrator access to your computer, install malware, encrypt all your data, and make you pay a large ransom to restore it. The best defense against ransomware is to pay one or two more companies to monitor and backup all the data on your server. That way, if bad guys do get to your computer, you can just delete it, and create a new one from your backups. Important insurance to have, but insurance isn’t free.
Maybe you’ll want statistics on how your application is used. Create an account with Google Analytics.
Want even more details about how people are using your app’s user interface? Create an account with a monitoring system like Hotjar.
Want your phone app available in app stores? Pay to create developer accounts with Apple and Google, and maybe give them 30% of any fees you charge your users.
Oh and one day your bank contacts you because they suspect fraud on your credit card. Easy for them. The bank just cancels that card and sends you a new one in the mail. But now you've got to remember all those places where you've used that card and go update them all with your new credit card number (Hope you remember all your User IDs and passwords!) And if you miss one, maybe the vendor will turn off their service because of non-payment and now your system stops working without warning.
The list of outside services and companies a modern software application must rely on gets bigger every year. Which means software developers must evaluate, learn to use, manage, and pay to use them all.
Is software so much easier to create now than ever before? No. Not at all. Just the opposite in fact. Luckily for our customers, the team at DelMar knows the best way to handle all this complexity.
Book a one-on-one meeting with our team to discuss how DelMar can help you manage the many aspects of modern development.
There’s an old saying in business: “If you can’t measure it, you can’t manage it.”
Early in my career in computing, I wasn't required to track my time. I came to work at about the same time every day, worked on programs the bosses told me to work on, then went home at about the same time each day. If a boss asked us, “How long will it take you write a program to generate this report?” we all did the same thing – made a wild-ass guess based on nothing but optimism, which was never accurate.
It was only when I first begin working as a contractor that I found tracking time to be a critical part of software development.
Time logs can be used to pay employees for the time they have worked.
Time logs can be used to invoice customers for the time employees have spent on their projects.
Time logs can sometimes be used to help with taxes for R&D and educational expenses.
But the most important benefit of time tracking is that real data is crucial for good project management:
Team members can compare their actual time with their estimates.
Managers can get statistical data from our time tracking system to know which tasks are completed, how much time they are taking, and how the task’s cost has affected the project’s budget.
Managers can review time entries to check that employees are working on the correct tasks.
The DelMar project management system has a client portal that allows our customers to see stats and details about their project anytime they are curious. For example, who is working on their project, which dates they worked, how much time is being spent, and the details about what was done.
And finally, time logs from projects in the past can be used to estimate how much time tasks on future projects should take.
At DelMar, we always log the time we spend on software development projects. We use a simple strategy, along with a project management / time tracking system we wrote for ourselves (naturally!).
We define tasks for every project we work on. Each task can have several levels of sub-tasks. For each task with no sub-tasks, we define an estimated number of hours. People who will be working on these tasks have input on what those estimated number of hours should be. We add up all the estimated hours to get an overall timeline for the project.
At least once per day, developers working on the project enter the time they spend on any of its defined tasks. Each entry has the current date, number of hours spent (rounded to 15 minute increments and almost always less than 2 hours each), and a short description of what work was performed. Because we wrote the software ourselves, we’ve built it into our normal workflow and made it super easy to create these entries.
Anyone working on a project can see all the tasks that have been defined, the number of estimated hours, and the hours logged so far. Which means everyone can see if the project is ahead of schedule, or if we are in danger of going over our estimates. If and when we notice there’s a danger of going over budget, our project managers get involved and discuss with our clients when needed.
DelMar has been tracking time like this since we started in 2004. Our database contains over 120,000 time entries for the 350+ projects we’ve done. This much detailed data give us a huge advantage when developing project plans and estimates for new projects.
Our system will save time and money on task management for your next development project. Schedule a chat with us!
There are so many apps and software solutions available to everyone today. It’s easy to assume that everything useful has already been made, and that all you have to do is search the Internet using the right keywords and you’ll quickly find software that does exactly what you need, for the price you want to pay. Sometimes that happens. But just as often, paying for a custom software solution is justified.
I like to use the analogy of renting office space vs buying own your own building for your business. If you want space for your business, you can easily search the real estate section, find a space with the square footage you need now, sign a lease, and move in. That might be great for the short term because your upfront cost is very little.
The downside is your space might look just like every other office in the building, you probably won’t get all the amenities you really wanted, the landlord won’t allow you to make many changes, you’ll pay the landlord forever, and the rent goes up each year. Your space doesn’t have a kitchenette so every time you want to make coffee you have to go down the hall to get water. Hired a few more employees and wish you could add some square footage for more desks? Too bad. You have to move your whole business to a new building in another part of town to get that sink and more space. Annoyances like this are common when someone else makes the rules.
Now compare renting office space with constructing your own building for your business. The cost will be initially higher, and it’ll probably take more time before you can move in. But the benefit is you can make your office work exactly how you want. You get to decide where and how big the rooms are. You choose the décor to make your space stand out from your competition. And you can be sure to include a nice kitchen so you can easily make those fancy coffees your employees love. Eventually you’ll have the building paid off and you’ll only have to pay for maintenance. Now you’ve got another asset you can leverage.
Software systems are like that too. If you rent software, the initial cost may seem cheap. Just $20 per employee per month! Which is fine when you only have three employees. But what happens when you scale your business and now have 30 to 50 employees? And you’ve used that software for 10 years? And the owners of that software raise the price each year? Now you’ve paid $100,000 over time.
Plus, that software never did everything you needed it to do, so you developed hacks and workarounds. It has a bunch of features you never use, you had to change your business practices to match that software’s workflow, your employees complain whenever they have to use it, and you have no competitive advantage because your competitors are using the exact same software. And probably the software's original creators sold out to a bigger company that forces you to upgrade to the new version which functions much differently from the system you originally liked, so now you have to convert all your data and retrain your staff.
If instead of renting that software, what if you invested $100,000 to have a custom system built? You can have 10, 100, or 1,000 employees using the system for no additional cost. The software can model the way your business works, instead of you changing your business to model the way the software works. Training new employees will be easier because the software will have your business’ rules built in, and the user interfaces will use the same terminology your staff already knows. The system will have the exact features you need, so no more workarounds and hacks. And you won’t be paying for features you never use.
Once built, you own this software, so you have another asset. Maybe your custom software allows your business to do something your competitors can’t do with their off-the-shelf rented system, so you now have a competitive advantage. Maybe your software is so great that other companies hear about it, and they want to use it too. And they’ll pay you to use it. Maybe pay you a lot. Much more than your original investment. Maybe some company with similar software is so impressed or afraid of your system they buy it from you for millions. Deals like this happen all the time in the software world. Go read about the history of Slack for a recent example.
For some tasks, renting software is a fine solution. Utilitarian tasks such as processing payroll for example. There’s no inherent benefit to doing payroll differently from others. But for everything else, ask yourself these questions before assuming renting is better than building:
How common is your problem, and how unique is your version of that problem?
How difficult would it be to modify your workflow to match the off-the-shelf software?
Is there something about your workflow that is actually a competitive advantage?
How important is the ability to scale and future flexibility?
Is custom software right for you? We can help you make the right decision for your business. Schedule a free consultation with the DelMar team.
When anything new is being created, the people doing the work have to make decisions. If you’ve ever done a simple home renovation – having a small bathroom remodeled – you know you have decisions to make. What kind of sink, what kind of faucet, what tile for the floor, what tile for the shower walls, how thick should the grout lines be, what color grout, where should the toilet paper holder be mounted … ? Hundreds of decisions.
If you’ve hired a contractor to do the renovations, you should expect they’ll make many of the decisions – what size trowel notch should be used for the thin-set under the tile? Other decisions are yours – should the shower tile be herringbone, vertical subway, or horizontal subway? But if you do the renovations yourself, you make every single decision. And making hundreds of decisions is time consuming and overwhelming.
When software developers begin designing and coding a new application, they too have many decisions to make. But instead of hundreds of decisions like a bathroom remodel, it's tens of thousands, and maybe even hundreds of thousands of decisions. Users and clients won’t know or care about most of these. Should we indent two or four spaces? What datatype should we use to store Airport Codes: strings, integers, enumerated types, or a lookup table in a database? Should the UI buttons have square or rounded corners? If rounded, what radius should they have?
For other decisions, users and clients should be involved. What features are critical to be included in the MVP? How should we arrange the user interface to be the most useful? Does the system need to allow ad hoc reporting, or can we build a simple way to download CSV files and let people use Excel to create reports in the format they want?
Good software developers will know which decisions they should make, and which decisions they need to defer to users.
Software developers are typically paid for the time they spend, so to reduce the cost of custom software, we should try to reduce the amount of time they need. The software development community has forever tried to make application development easier. We’ve done so by creating new programming languages, tools, code libraries, data storage techniques, and methodologies. But each time something new is introduced, it actually increases development time because now there are even more decisions for the development team to make. Which DBMS should we use? Which HTTP verb should we use for this endpoint method? GET, POST, PUT, PATCH … ? (Answer: Just use POST. It works for everything, and now you've got one less decision to make.)
At DelMar, our software developers strive to decrease our time and costs. We do this by following patterns, using published coding standards, reusing code we've developed, not over engineering solutions to simple problems, and not changing tools just because something new has come along.
We also encourage our clients to reduce the decisions we need to make (and hence save themselves money) by making as many decisions as they can before talking with the development team.
Think of the software development process the same as you would when doing a bathroom remodel for your house. Make a list of requirements before talking with architects and contractors -- my new bathroom must have double sinks, a walk in shower, and radiant floor heating. Then create inspirational Pinterest boards of things you like that other people have done.
For software projects, make a list of desired features for the system, separating them into "must have" vs "nice to have" categories. Decide which computing platforms your systems should support -- does it need to work on all web browsers, or just desktop Chrome? Also create a folder with screenshots of the user interfaces of other applications you like -- I really like the colors used by PayPal, I really like how Wayfair allows you to search for things, and that font used on WarbyParker.com is cool.
Any decision you can make before getting the development team involved means less time needed by the development team, which means less money you’ll have to spend on your new application.
Do you have a list of things your application needs? Contact us to discuss how to streamline your project.
Like most industries, the software development community uses loads of industry-specific buzzwords that people outside of our field don’t know. And the software development community is especially good at creating new words to replace perfectly good words just after everyone got used to them. (Who started using the term “endpoint” anyway?)
At DelMar, we use certain titles for the roles on our development projects. Different firms may use different titles but don’t let that confuse you. The tasks these roles perform still need to be done no matter what name you give them.
Also note these names are for roles on a team, and not necessarily job titles or different people. On most projects, multiple roles can be handled by a single person. For example, the business analyst and project manager roles often are handled by one team member, or the system architect and backend developer could be the same person. On very small projects, all roles may even be handled by just one person, but having a single team member who is good at all roles is hard to find.
Roles on the Development Team
Business Analyst – Works closely with domain experts, understands the business needs for the software, and communicates these needs to the development team
Project Manager – Makes sure tasks are completed on time and within budget
System Architect – Designs at a high-level the technical components for the entire system
Frontend (FE)/User Interface (UI) Designer – Designs user interfaces using lo-fidelity mockups (aka, wireframes), hi-fidelity mockups, and minimal functioning prototypes
FE/UI Developer – Codes and tests user interfaces for:
Desktop Web Browser
Mobile Web Browser
Mobile Native Apps (Apps in phone app stores)
Native Desktop Apps
Backend (BE) Developer – Codes and tests application business logic that runs on servers, and defines data storage and database design
Quality Assurance (QA) – Ensures all parts of the system function as designed
Server Administration/DevOps – Deploys applications and monitors backups, OS patches, malware prevention, security audits, etc.
Mentor – Works one-on-one with junior developers to offer advice and insight
Trainer – Works with multiple developers and/or end users at once in a classroom environment with planned lessons, assignments, and feedback
In addition to the roles on the development team, the people who the software is written for have roles. Again, these roles aren’t necessarily different people.
Domain Expert – Understands the business needs for the software
End User – Eventually uses the software
Champion – Keeps everyone enthused about the project and convinces the financial backer that getting the software built is worth paying for
Financial Backer – Pays for the software to be built
Feel ready to take on a customer role with DelMar? Send us a message to get started with a free consultation.
How do you describe software development to someone who doesn’t already know it?
When I first went to college in the 1980s, I learned computer programming and I would tell people “computer programming is typing instructions to make the computer do something”. But typing instructions is just a small part of modern software development.
Now when I describe how DelMar does software development to someone who is unfamiliar, I compare what we do to what people in more familiar industries do. My favorite analogy is new home construction, but I sometimes also compare software projects with how a Hollywood movie is made – especially when making a distinction between the role of the project manager and system architect/technical lead.
Big-time Hollywood films seem to always have two roles at the top of the responsibility hierarchy – directors and producers. According to Wikipedia:
A film director's task is to envisage a way to translate a screenplay into a fully-formed film, and then to realize this vision. To do this, they oversee the artistic and technical elements of film production.
A film producer is a person who oversees the production of a film. The producer is tasked with making sure the film is delivered on time and within budget, and has the final say on creative decisions.
These roles require different skills and different personality traits, but both roles are equally important to the success of the film. A bad producer and the movie will go over budget. A bad director (or worse, too many directors), and the movie won't tell a clear, consistent story.
The team creating a new software application also benefits from having two different people, with different experiences and personality traits, that serve these two roles, at the top of the responsibility hierarchy. We can change a few words in Wikipedia's definitions for film makers, and they sound just right for software development teams:
A system architect’s task is to envisage a way to translate a requirements document into a fully-formed software application, and then to realize this vision. To do this, they oversee the technical elements of production.
A project manager is a person who oversees the production of the software. The project manager is tasked with making sure the software is delivered on time and within budget, and has the final say on creative decisions.
We make sure each of our projects has the right director and producer to make the best possible software. Schedule some time with us today.
I’ve been working in computer software my entire professional career. When I was in high school, I really had no plans for myself after graduation. I was fortunate that a boss I had at the time advised me to go to college and study computers. This was in 1980, when personal computers were only used by electronics hobbyists. I had never even used a computer, but I didn’t know what else to do with my life, so I took that advice. It took me a couple of semesters to understand how to make computers work, but I found my personality was a good fit for a career in “the exciting new world of computer programming”.
There are many benefits to working as a software developer. It pays well, you can work in just about any city, and it usually doesn’t require heavy lifting or working outside in bad weather. But jobs should also be personally fulfilling, so when I talk with college students or job applicants, I always ask, “What about this job motivates you? Why do you want to do it?”
Over the years, I have found six general types of people who enjoy software development:
1. Some people like gadgets. I’m sure you know someone who always seems to have the latest TV, phone, game console, security cameras, home automation system… Computers are always evolving so there are always new toys to play with at work.
2. Some people are investigators. They are naturally curious. They like to know how and why things work like they do. They like to understand complex systems and sometimes challenge themselves with puzzles. Software systems can get seriously complicated, so enjoying the process of figuring things out is great trait for software developers. After all, to safely make a change to those hundreds of thousands of lines of code you just inherited, it's best to understand how it works before you start.
3. Some people enjoy being the expert. They like to be the one that people turn to when for advice and new information. They are self-motivated to know as much as possible and keep up with everything new with some technology. “Why is this SQL query running so slow?” “I don’t know. Let’s go ask Cindy. She knows everything about PostgreSQL. She’ll tell us what to do to fix it.” Again, computers are ever evolving and the breadth of knowledge is so huge, there’s plenty of things to become an expert in.
4. Some people like to invent new things. They have ideas for things that don't exist in the world. Maybe they think they’ll get rich. Maybe they’ll make the world a better place. For people like this, being able to write software is a great fit. Most inventions require a substantial money investment to buy physical machinery and tools, raw materials, and lawyers. Have an idea for a new way to use your computer to send messages to your friends? A new way to buy a used car? A new way to keep track of your expenses? Great, all you need is the laptop (you most likely already have), some freely available programming tools, an internet connection, and time.
5. Some people like be a help to others. Someone has a problem. You help them solve that problem. They thank you for helping them. Now they are happier, and this makes you happier. It’s a great feeling.
6. Some people like to make and build things. This is similar to being an inventor, except that makers aren’t motivated by building things they personally dream up. Instead, they get personal enjoyment from building things other people want. They like that they’ve collected tools, know how to use them, and can use their tools and skills to make something other people want. If you need custom cabinetry built for your kitchen remodel, or maybe a new iron gate for your front yard, you go find a craftsperson to build it for you. The same kind of people exist to make custom software applications for your ideas.
At DelMar, each member of our staff has a little of all these traits. We all have some gadgets, we all like to investigate and figure things out, we continually learn and have expert-level knowledge on lots of software related topics. We even have ideas for brand new apps no one has imagined before.
But mostly, we think of ourselves as helpers and builders. If you’ve got a problem you think can be solved with computers, or need something custom built, contact us today. We’d love a chance to talk to you.
Ready to take your business to the next level?