+972 52-548-6969
On friction in software
I was pointed out to this article about friction in software, in particular, because I talk a lot about zero friction development. Yet the post show a totally different aspect of friction.
I would actually agree with that definition of friction. The problem is that there are many types of frictions. There is the friction that you have to deal with when you build a new project, in a new domain or using new technologies, so you need to figure out how to make those things work, and you spend a lot of your time just getting things working. Then there is the friction of the process you are using. If you need to have a work item associated with each commit (and only one commit), it means that you are going to either commit more slowly, or spend a lot more time just writing effectively useless work items. Then you have the friction of the common stuff. If your users require you fairly elaborate validation, even a simple date entry form can become an effort taking multiple days.
All of those are various types of frictions. And all of those adds up to the time & cost of building software. I tend to divide them in my head to friction & taxes. Friction is everything that gets in the way unnecessarily. For example, if I need to spend a day making a release, that is friction that I can easily automate. If I need to spend a lot of time on the structure of my software, that is friction. If I have checklists that I need to go through, that is usually friction.
Then there are the taxes, stuff that you do because you have to. In my case, this is usually error handling and production readiness, failure analysis and recovery, etc. In other cases this can be i18n, validation or the like. Those are things that you can streamline, but you can’t really reduce. If you need to run in a HA environment, you are going to be needing to write the code to do that, and test that. And that ain’t friction, even though it slows you down. It is just part of the cost of doing business.
And, of course, we have the toll trolls. That is what I call to those things that you don’t have to do, but are usually forced upon you. Sometimes it is for a valid reason, but a lot of the time it is Just Because. Example of tolls that are being laid upon software include such things as having to integrate with the CRM / ERP / TLD of the day. Being forced to use a specific infrastructure, even though it is widely inappropriate. And, possibly the best thing ever: “I went golfing with Andrew this weekend, and I have great news. We are a Java shop now!”
Comments
All great examples of friction for sure, but the first thing that came to mind for me was what I'll call "user friction". The reluctance of users to change the way they work, even if change will make them more effecient/effective/productive/etc... Sometimes it's amazing the amount cultural inertia that must be overcome to affect change.
Can we assume that spending time on code structure is both -unnecessary -unmandatory
I wouldn't put integration with the rest of the business systems as a toll, provided that those systems were in place long before you showed up. The sad fact is they are already in place and the business relies on them for a lot of their reporting needs. And I say this as someone who has to fight these systems on a daily basis; I'd like nothing more than to nuke them from orbit :)
Patrick, Spending time on the structure of the code is very wasteful. Please note that I didn't say that you shouldn't pay attention to your _architecture_. For example, look at a typical N layer sample app and see how much time you need to waste of structure if you want to make a change.
João, A lot of the time, there isn't actually any value in using them except being able to say that you used them.
Oren, caring for dependency, organization, design, testability, mutability, metrics, dead code, duplicate code, naming, API usage... Call it very wasteful, I call it very essential because it'll avoid a much more serious waste when new features will have to be added and bugs will have to be fixed.
For example, look at a typical spaghetti/unstructured sample app and see how much time you need to to waste just to assess where and how to make your change, and actually make it works.
Patrick, Take a look at my code. There is a lot of it available, and much of it has been around the block for a good long time. I design & architect for the people who are familiar with the codebase, because that is more efficient long term. Having strictly adhered and "obvious" architecture may help the newbie, but that is only going to hinder anyone else. And I don't cater to those in my codebases.
Being familiar or not is something that can change. There are plenty of vast lumps in my code I haven't touched for 2 or 3 years and still the code run daily in production. Sooner or later I'll have to do some maintenance on it and I won't be familiar with it anymore. Hopefully I'll be familiar with the habits/tenets I used to structure the code at that time and this will help a lot.
Spending resources on code structure doesn't hinder me. I see it exactly like unit-tests, and the advanced version of unit-tests, 100% coverage + DbC. At the beginning it looks awkward and waste, but once I've tasted the immense benefits, I cannot develop without.
Personally, code that works is not enough to be done with a feature: code that works + well structured + 100% covered by tests + DbC everywhere, is my checklist to be done.
Patrick, I think that we are talking past each other. It is quite easy for me to run into code that I haven't seen for year, but that doesn't mean that is is bad code. When I am talking about structure costs I am talking about things like this post: http://ayende.com/blog/155073/reviewing-xenta-and-wishing-i-hadnt
Places where you have to do a bunch of stuff just to make the architecture gods happy. Compare that to how most of the stuff in RavenDB, for example, is built. As independent components that are plugged together without really caring for each other.
In the Xenta post, we can show a project wrongly structured, which is obviously a waste.
My point is that I found praising "code structure is a waste" a bit provocative because:
1) you do structure your code (since RavenDB component are loose coupled), with the experience you are able to keep this task in the flow of coding to minimize its cost
2) structuring code is not a waste, because it prevents from the threat of completely unmaintainable/spaghetti/entangled code
3) a junior developers that reads your position on code structuring, might well end up applying this "zero code structure advice" to get "code that works" as quickly as possible, with the result we know
Comment preview