Reusable abstractions should not be designed – we should not try: because our knowledge falls short of encompassing such problems: we cannot consider all uses and we cannot predict the future. Instead, large-scale under-specified abstractions should be evolved – they should emerge passively from everyone collectively. And our design effort should only be on the rest: the smaller, clearer, work needed to address particular problems.
We should describe rather than demand. Instead of making standards demanding adherence, we should focus on describing clearly whatever we do do. Again, as above, a standard depends on the original intention actually fitting future use, which is unreliable (and compliance is another problem). But describing is ‘local’ and much more strongly feasible.
The activities of assembling and modifying should be (more) formalised. Since design is substantially about reusing and adjusting it is probably good to give such transformation activities a clear structure. Formalisation and discretisation is the most essential basic idea of software, but it seems we could probably do more modularising of transforms, as well as products.
These three work together. Particular design is built from previously evolved pieces. Good description enables effective filtering and finding of those pieces to build on. New parts may or may not themselves evolve to popularity, according to what actual use decides. Formalised transforms clarify use and reuse, and so are a basis of good description of design.
And that can be expressed as a normal kind of simple process, that feeds back into itself iteratively:
The suggestions are founded on some well-appreciated or easily visible ideas.
From Brooks' ‘No Silver Bullet’: accidental details like language, tools, etc. are insignificant compared with the essential complexity of the problem, and the only way to substantially improve development is reuse. If you can easily find some code and copy it, you get the result at zero cost. That is an efficiency that cannot be beaten: no amount of programming tool and technique improvements can ever do that. So we want to maximise reuse.
The nature of software, and the infrastructure of the internet, means its maximum development scope is global. And the nature of software is also to be easily changeable, and there need not be any real start and end points, so the process can be continual. Software imposes no normal physical limits on development, so development should be expanded to maximise the effectiveness of its constituent practices.
One of the key propositions of eXtreme-Programming is that ‘designing’ speculatively creates risk. You cannot simply design something ‘flexible’: it is likely you will design the wrong thing and not use it, and the effort is wasted. (Yet is not the purpose of design to reduce risk? – by using knowledge you know works? Really, the more design is speculative rather than based on firm knowledge the less it really is design at all.) So we want to design only for what we know.
Evolution can produce things that work, but they may not be what is wanted – evolution is not done to order, it directs itself. But in the cases where we cannot design we do not know what we want or how to do it anyway, so there evolution fits nicely. Evolution and design are complementary. As Linus Torvalds has observed: large-scale software cannot be designed well, but must be evolved.
And of course this all presupposes the software is open-source/free-libre. There can be no fully-functioning globalness/continualness, evolution, or reuse otherwise.
The most powerful resource in programming is information flow.
To think of programming as a problem of how a person builds some software is to view it or frame it in a very industrial craft-like way. But software development is not a materially limited activity.
Software is immensely about what happens between all the people doing the programming. (Think of software not as individual things that you make and finish, but as a single big thing that the whole world makes and continuously adjusts.) So just as much, and perhaps more, than addressing how to make programming better, we should focus globally on how to make finding, accessing, and copying programs better.
The questions to tackle now, in ways that fit this global evolution perspective: