4 ms·
>So how can we go about writing code that is least coding? In general, when one works out the design (as has been apparent many times from personal and anecdota
by azov 15y ago
>So how can we go about writing code that is least coding? In general, when one works out the design (as has been apparent many times from personal and anecdotal experiences) well in advance before writing code
Can't agree with this advice. Figuring out the design before writing code is not going to work because you simply don't understand the problem well enough before you try to implement the solution. It is that first prototype that helps you gain knowledge, discover practical use cases, prioretize features, etc. The design that you "figure out" without writing any code will most likely be inadequate.
The thing is - you want to minimize the amount of code you end up with, not the net amount of code you write along the way.
PS. Two exceptions:
a. your problem is trivial;
b. you've solved a similar problem before.
- beobab 15y agoI sort of agree with you; Code to find the edges of the problem, design to work out what to do, and back to code to implement. Sometimes the only thing that saves my sanity is a nice process diagram in the design phase, which makes me realise that something important has been missed.
- bigiain 15y agoAdvice from a long time ago that took me way longer than it should have to understand fully: "Always throw the first one away." I now consider the entire first prototype to be part of the "working out the design" process, and all the code written for that is considered disposable (quite often I write a prototype in a different language to the intended delivered product, partly to ensure I throw the first one away, but when I'm honest with myself - at least partly 'cause I enjoy rapid-prototyping in Perl.)
- barefoot 15y agoAn important corollary to that statement is: "And never show the prototype to non-developers".
- debacle 15y agoThis is probably my biggest fault. "So I whipped together a quick API integration yesterday evening..." "Oh, so you're almost done then!"
- beagle3 15y ago... except those who are the users of your system. No product design survives first contact with users, and it would be a waste of time if you do not use feedback that the first prototype can get.
- jacobr 15y agoHow about writing something quick and then refactoring aggressively? The prototype code would kind of be the design specification. After the second or third big refactor my code is much shorter and starts making some sense...
- einhverfr 15y agoWell, I disagree with you. However by "design" I don't mean figuring all the implementation details out ahead of time. It means looking at the requirements, what solutions already exist, and figuring out the most elegant way to string together what you have and fill in the holes. Now, IMO, this design never means writing a spec. It means thinking through things however, from an architectural rather than implementation perspective. It means thinking through the larger problems regarding how the pieces of your program will talk to eachother before you begin. Then when you start coding, the only design questions you have left to answer are those which involve the sorts of details you won't know in advance.
- adrianhoward 15y agoAgree completely. The first thing I thought when I read this was that it was going to be talking about the old extreme programming adage of YAGNI (http://en.wikipedia.org/wiki/You_aint_gonna_need_it http://en.wikipedia.org/wiki/You_aint_gonna_need_it) - only to find that it came to the exact opposite conclusion :-)
- wpietri 15y agoYes. One can only understand the design space by exploring it.