MyCareerNetwork
MyCareerNetwork needed a partner to provide guidance on maintaining and expanding their software products for the HR industry.
Featured team member
Jason Still
Jason is a graduate of the University of Louisville Business School’s Computer Information Systems program. He began his career in software development in 2003, but his fascination with computers and programming began much earlier. Jason wrote his first code in the early 90’s on an Apple II, copying BASIC programs out of the back of his elementary school math book and then making changes to try to understand how it all worked.
Full bio →Services we offer include…
- Custom software development
- Web applications
- Desktop applications
- Mobile applications
- Database applications
- Data warehouses
If It Happens Less than 1% of the Time…
We’ve all come across these scenarios. We have the perfect design, the perfect code, an unbelievably intuitive and easy to use interface, and then bam!
Someone mentions some special case you hadn’t thought of or because you’re an obsessive programming perfectionist, you think of some off the wall scenario yourself.
Crap, now you have to mess up your beautiful and perfect code, destroy your intuitive interface, and re-think some other piece of functionality you completed over two weeks ago!
Special cases are obnoxious. They make things complicated ($$$), push back deadlines ($$$), and make your life miserable. If only we didn’t have to program for them…..
But what if we don’t program for them? We can’t do that can we? We need to cover every possible scenario or the app is incomplete! What if the user does this, hits this, does a back flip and then clicks that! It could happen!
Guess what, in the grand scheme of things IT DOESN’T MATTER.
We’re not building software to please 100% of the audience. We’re not building software for the sake of building perfect software. We’re building software to make someone money.
We’re consultants. We need to keep our eye on the bottom line. If something happens less than 1% of the time than chances are good that there is no ROI.
But what if it’s the business users who insist you code for some off the wall scenario? Surely you must do it then?
Maybe, but only after you’ve enlightened them as to why you shouldn’t. And as a programmer, you should not be talking about how it makes your code more complicated because nobody cares.
Instead, ask them how often the scenario will happen. Ask them how much money it will cost each time it happens. Ask them if there is a manual work around that can solve it. Then tell them it will cost $20,000.00 to fix it in the short term than an extra $5,000.00 annually (it now takes twice as long to add a new feature!). Not x hours, but x dollars. There is a psychological difference. When talking about hours the consequence of spending the money isn’t obvious. It needs to be. Your reputation depends on building software that make someone money.
At first glance nobody likes the idea that some special case scenario is not handled. It makes you feel like your software is incomplete and people worry about it more than they should because they think about it without context. But remember why you’re doing something in the first place (make someone money) and you’ll feel a lot better, your client will be happier in the end, and your software will be better for it.