After what has been a crazy 48 hours of work. I have been dealing with a dozen different technologies and have barely slept a wink in the mean time. Lets dig into Agile Principle 7 before I fall asleep on you nice people.
Agile Principle 7
Principle 7: Working software is the primary measure of progress.
https://agilemanifesto.org/principles.html
Now there is a statement I can get behind. One of the big things in my entire career is, I rather have a working but crappy written program than a perfectly engineered failure. This is probably due to my business training but I think the spirit of Agile Principle 7 is there.
I get it. Ideally you want a perfectly engineered working program but that is often not how things go. There are times that perfectly engineering is bad and wasteful. Reusable code take 3 times as long to build. If the problem is a small one off then code as such.
Often the crappy pieces of working code are one of these small one offs that’s role has expanded. It is better to refactor this exception to the one off coding problem than it is to do it “right” the first time. You will waste more money as an organization doing things “right”.
Deliver value to the customer by delivering working software faster. Yes it might grow. At that point, refactor what you have and start doing it right the rest of the way. Remember this is an iterative process and cleaning up the mess from when you thought the program was just a one off is a legitimate expense. The alternative is 3 times more expensive to the customer.
We forget as programmers that the end user of the system does not care if everything is wonderfully under the hood. They only care about the stuff they see.
Are you sanctioning bad coding behavior?
No, I am not. Try to keep things separated. Don’t mix the data code with the GUI or anything like that. Try you best initial design but don’t get hung up with making it perfect.
Try to separate you GUI, from your controller, from your database. But if our models are not as clearly named as they should be or some logic slips into the code behind. Don’t kill yourself. Document your screw up when you notice it and keep trucking. Most likely this one off will never be manipulated again. Use documentation when things are a little unclear.
Basically, try your best quick design. As you get more experience the quick design will be closer to perfect but don’t stress when you are not perfect. Get it working. Document anything that is unclear that you see and move on.
Just a personal observation about perfect coding. I know when I get too focused on perfect code, my code improves and my end product suffers. I either fail to deliver fast enough or don’t spend enough time on the GUI, which is where 99% of the value the average customer will give an app. That seems like that statement should be wrong but a working app with a bad interface seems to always deliver less value than a halfway working app with a gorgeous interface. People and shiny objects, it is weird.
I have no idea how this stream of consciousness post is sounding but remember.
- Software delivers value.
- The closer to what the customer want it to do, the better the software value is.
- Perfect Computer Scientist approved code does not always deliver good value.
- You as a dev need to focus on delivering good value.
- Good Value = Working Software