Bad Software Development Principles and How to Fix Them
Most of us working in Software Development have experienced “The Good, the Bad, and the Ugly”. I’m here to talk about the Ugly.
Throwing people at the problem
I have seen times where a deadline needs to be met. Usually in professions like Construction, Manufacturing, and the like, adding more people to a project gets it done faster. This is not the case for Software Development.
Hiring new members to the team that are not experienced with the architecture of the project, nor it’s complexities, will need time to ramp up. This not only further delays the product, it can also cause more bugs to be introduced.
Solutions
- Limiting the scope of the project
- Better management of resources
- Pushing back the release date
Everyone should read The Mythical Man-Month. I think its a good book that goes over the details.
Meeting unreasonable “BIG” customer requirements
When building software for the masses, we need to make sure we are covering all bases with what customers need. It always makes sense to do market research and find out what those needs are.
Sometimes you have “high paying” customers which may have some weird, unreasonable requirements which break what the product is trying to achieve. A team may drop everything and work to implement a particular feature. This newly introduced feature for one customer, may introduce new unexpected bugs for the other 99% of customers.
Solutions
- Do what makes sense for the future of the project
- Work with the customer to find a solution that makes sense
Customers will place more trust in you knowing that product is secure and stable. It’s better to work with them, than for them, when developing a product. They will appreciate it!
Reinventing the wheel
Custom solutions are not always required. There are tools out there, which in most cases are cheaper than the cost of developer hours.
Have you seen cases where a developer works hard on a particular tool, only to realize that it looks alot like a tool you’ve seen before? More time could have been focused on the actual product over development of the tooling.
Solutions
- See whats out there before starting to develop it
Although they are seemingly more expensive, third party solutions can end up being cheaper(even free). If an OpenSource tool has most of the features you need, but not all of them, why not just contribute them to the Community.
Really bad team leadership
This is a big one. Leadership can make or break a team. Employee morale is key to not only getting things done faster, but also to keeping your best employees. A coworker of mine told me once:
“More time in the office does not equal more work gets done”
and it goes through my mind sometimes when I think about working from home.
You would be surprised of how many places I’ve worked which were very unreasonable. I couldn’t leave the office for anything(Luckily today, I have a flexible schedule). It made me feel trapped, and eventually I associated work with stress, even though I liked what I was doing.
Solutions
- Be better to your employees
- Be more flexible with schedule
Let your employees leave early before holidays. Let them be able to take off when needed for emergencies or to care for their children etc. Be ok with employees working from home. People will do great work for you, when you are good to them.
Listen to employee opinions, make sure that everyones needs are being addressed. No one wants to be working on something they don’t understand.
Not caring about the beta product
We should put the same quality we expect out of the end product into the beta version. Ignoring important details because “It’s only beta” is unacceptable. If we don’t really care about beta, then we wont care about the actual release.
We need to let customers know that our product is great from the start!
Solutions
- Treat beta as a real product
After all, you want your product to be successful. Also I don’t think anyone wants to become “The Master of Refactoring” after GA.
Ignoring the small customer
Small customers grow. They blog and share their experiences. Don’t Ignore them. If you get a chance, help them grow. It will do nothing, but benefit you.
Solutions
- Don’t neglect the small customer
There should always be an initiative to help all customers as long as their requirements are reasonable.
“Customer Obsession” does work.
Constant Deprecation
Have you ever seen version 1 APIs, and a few months later version 2 and so one and so forth? Then version 1 is instantly removed. You had built your automation around version 1, and now everything is down. Yikes…
Customers hate constantly having to change things. Software is expected to work as is without change.
Solutions
- Have a plan for deprecation
- Don’t do it too often!
Having a plan for deprecation is very important. The customer needs to know very well ahead of time before an API or Service is removed. Constant changes makes the customer feel like the product isn’t fully realized or stable enough and can turn them away.
Not taking ownership and blaming others
We’ve all worked with that one person who would make mistakes, but would blame them all on others.
There was a huge bug introduced to production by Edward. Edward blamed it on Humphrey’s API documentation. In reality it was not Humphrey’s fault for the major production bug.
There seemed to be a lack of communication. Edward should have reached out if he did not understand the documentation. He should have taken responsibility and worked to not only correct the production issue, but also the documentation.
Solutions
- Take ownership for what you do
Make sure you work with your team and overall organization. If you don’t understand something, seek help. Blaming others solves nothing and will only hurt you.
Chasing the hype
A friend of mine once sent me an article on Hype Driven Development. After reading I began to realize that so many people like to follow the hype. Imagine just browsing /r/programming, reading a couple articles and leaving the future of the product to what you’ve read. Let’s follow the Spotify Model, it’s cool right. Add in some NoSQL for NoReason.
After alot of hard work, the product is complete, but theres one problem…
…well a few problems. It doesn’t scale, It’s too modular, theres a million dependancies and some are being deprecated, 1/2 the team left and it’s hard to find replacements, etc. etc. Now everything needs to be rewritten. It’s what I would like to call Fail Slow.
Solutions
- Do what makes sense for the project from the beginning
If you shouldn’t use the coolest new technologies(I know you want to), then don’t use them. Sometimes it’s a good idea to chase the hype, but only if it makes sense for your application.
SpongeBob found out, he wasn’t ugly. He just had bad breath! Much like the examples above, its not the team that’s ugly, they just smell bad and need some metaphorical mouth wash.
I would suggest reading Amazon’s Leadership Principles. Marc Hoag has a really good article on Medium as well. Those principals have been tested and are proven to work. They are the metaphorical mouthwash.
