Make it run, make it right

The practice of first making things run and then proceeding to making them right in software development is something I've always been adhering to — at least for each particular "atomic" task. Advantages are numerous: you get a proof that something is possible and/or understanding how hard technically that is, you and your customer (or analyst or PM or whoever is interested) can see the result and change things until it's too late, and the risk of not doing the task on time is reduced.

However, it still leaves a lot of room for choice for the developer: suppose you have an iteration during which you are planning to do 10 features. What will your best strategy be: trying to make each feature in its entirety by first making it run and then refactoring it to the point where you consider it to be right? Or rather make all 10 run first then refactor? Choosing somewhere between?

Each of the strategies has its good parts and its downsides. If you are doing everything run, the customer may ponder a feature, get some UX on it and come back with a change later until you started refactoring it. You also start refactoring with more requirements in mind and can make more accurate decisions. On the down side, if no time is left for refactoring you are left with a pile of hacks; and while making things run this piling up of hacks can also slow you down substantially: you don't have right abstractions. Interaction with other developers is also substantially hindered as you are not communicating your intentions clearly to them. And there's also a risk of the customer starting to seek perfection and drown you in changes until you get a chance to refactor.

Downsides of this approach are clearly bright sides of the contrary one and vice versa. If you don't get your features done during the iteration, they are likely to be moved to the next one. Release date may be shifted further and further and the product is put on risk.

So as the bottom line I'd say this: if your customer wants to have something that can be used, promoted etc. while the next version is being developed, be it with some warts and errors and things not perfect, and if both you and the customer understand that the first version will not be supported and is likely to be more thrown away than refactored, and if the whole thing is not so monstrous that it will start falling apart until you are finished (either because things get tangled for yourself even or for lack of communication in the team of developers) then you are probably better off with the "make ALL run, then make it right".

Parameter objects for API

I've always been interested in which paradigm to prefer:

declare functionName(concreteArg1, concreteArg2, ...)

or

declare functionName(containerArg)

Here, containerArg is an argument of our type with methods returning concreteArg1, concreteArg2 etc.

I usually preferred the former way as it allowed more concise implementation body and also the method signature speaks for itself. And also we don't introduce a new type. And the calling code is shorter.

There's a substantial difference in favor of the latter though: if later you decide you need to pass some additional parameters (or you don't need some), you can easily do that if you are passing an instance of your own type, but you are screwed if everything is specified in the API: you cannot but break API (or add another almost duplicate method), and even if you are the only user of the API you need to change calls and implementations etc. in every single place.

Such a simple thought and has never crossed my mind until I stumbled upon it.