The purchase order system you need to build should be easy.
All the user has to do is select a supplier from the list of registered suppliers that you deal with, then enter a series of parts, descriptions, and quantities, and you're done. Print it off, mail it, wait for the order to be delivered.
You write the code in a week, and you sit back, waiting for praise and thanks to shower on you for the wonderful job you did.
What showers down on you, instead, is fifty shades of batshit
Users get half-way through entering an order, then notice a mistake on one of the earlier lines. But you gave them no way to go back up the screen so they have to scrap it and start again.
Users start, then realize they need to look up a product code, but they can't leave an order half-finished. They have to scrap it and start again.
It gets worse if you do reach the end of your order, because there's no opportunity to review it before it gets automatically printed off, or electronically faxed if the supplier is set up that way. Because you were being quick and efficient and decided to save them precious time. Orders are flying out the building with mistakes in them, that your company is being invoiced for by your suppliers.
And just because an order was correct at the time doesn't mean it will stay that way. One supplier is out of stock so you need to re-order either an alternate part or from a different supplier. But your system is expecting all goods ordered to be delivered. There's no means to cancel an order once placed.
Then the supplier only delivers five of the eight items ordered. The rest will follow next week, but you assumed it would all be delivered together and didn't think of part shipments.
All this adds up to one simple lesson...
Coding the happy path is typically less than 10% of the work in developing a system. If you only work on the happy path to save time, you'll be in a world of hurt later on.
Dealing with the unhappy paths should be the lion's share of your effort, and doing so gracefully marks the professional from the amateur.
Subscribe to:
Post Comments (Atom)
Posts
4 comments:
That's so interesting because it shows all the different paths and thought processes coders need to go down in order to make something work really well. It also explains why programs constantly need updates....to deal with oversights that become apparent only from heavy usage.
The reason we have coders and software developers. Guess who gets paid more? Well, I HOPE any business knows the difference between the two. :D
If a developer has worked with client server applications and relational database design, they have a deeper understanding of why these problems come up with hot shot put together quickly systems. Complexity exists for a reason.
Johanna, there's nothing like real-life usage to find ways to break your system that you never imagined in testing :)
Diane, the problem is when the folks cutting the corners get to make unrealistic promises, while the more seasoned folks are saying that ain't gonna work. Guess who the company execs believe?
Then the corner cutters get promoted or leave for another job and now you have to maintain the monster they created because you can't get it put into the budget for a rewrite. lol
Post a Comment