Hacker News Reader

Comment by stephengillie | Hacker News Reader

Sometimes I'm surprised at the lack of parallels between writing long-form articles and writing code. How many people draw a general outline of their program, what they want each part to do, and how the whole thing should be layed out? Who plans before they start coding it?

View on HN

Code is a planning language, so rather than boxes and noodles or pseudocode, I tend to sketch out my plans in code itself. In SICP this is called "design by wishful thinking": you pretend that you already have a library of primitives that do the nitty-gritty work and write the high-level bits of your program using those primitives. Then, you go back and implement the primitives.

It's surprisingly effective.

Indeed, the "design by wishful thinking" was a real eye opener for me. It is one of my favourite parts of SICP.

It can also be explained as way to postpone decisions you can't clearly make right now. First, you pretend to have made the decision, and later on you implement the decision "you wish you had made".

> "design by wishful thinking"

aka coding by intention

Definitely an effective technique. Personally I like doing this on a whiteboard so I don't get distracted by errors or Compiler/IDE notifications and can just sketch mostly in realistic looking code.

For smaller segments though, I'll just write out function signatures, an then go back and fill em out or restructure them.

This is also known as top-down design.

I think these types used to be derogatorily referred to as "cowboy coders" in the 90's by overly process oriented developers who came from an era of mainframes and punchcards.

I think a big shift in modern software development came about when people finally realized that developing software is by nature a "messy" process. Loose text files, REPL sessions filled with red lines on the console, randomly scribbled boxes with arrows on loose sheets of paper strewn about the room; traversing object graphs in your head while on the drive to work. There is no "outline" to frame any of that. The outline only exists after the software has been built.

Maybe I've been spoiled by working with embedded C++ on Arduinos, where we have 3 sections -- Initialization, Setup function, and Loop function. We set variables and include libraries in the Initialization section at top. We run first-time code and open serial & other connections in Setup. Most code goes into the Loop section, which is the function that does the heavy lifting. Extra functions (i.e. the math to convert inches to mm) can be written below, and called in either Setup or Loop.

This is why programming language history is so important. Every programming language has a large number of opinions/assumptions. Code structure is one of them. The Arduino language, based on C/C++, has assumed a simple code structure that helps people learning embedded programming, because the Arduino platform was designed to help people learn.

AMEN!

Sadly that does not work in enterprise multi-site projects with outsourcing across several companies.

Yup; which is why the people getting hired for those projects would flounder if asked to make a large individual contribution without much handholding; and also why those types of project team structures yield such incomprehensibly shitty software (at ridiculous cost to the client.)

Seriously? Many of the enterprise devs I know do make large individual contributions in their own (side) projects, or in smaller projects within the organization. Part of enterprise dev is that you are developing within a series of constraints, not least the thought in mind that there is likely to be someone maintaining this code in 10 years time, and it's unlikely to be the team building it today.

I would agree about the general outcome, though - enterprise software often is built _despite_ the politics between various departments and vendors, and much of the solution is as a result of compromise and integrating with "not quite suitable for current purpose" legacy systems. That is where a large amount of the cost goes. (It's also important to remember that what we're building today is also going to become the legacy system of tomorrow, and to include that thought in the design).

That is also my experience.

developing software is not messy process. what is disturbing is that you think it is and that is normal state. Sure it is messy if you develop by accident so lets see what sticks.

> .. messy ..

Design is messy. The implementation need not.

> “Design Patterns”, “Code architecture”, “Scalability”, “OOP”, “Maintainability”

Apart from Scalability others can be implemented from day one.

Scalability is about a dumb proxy first. Change in Data structures next.

In software, you have two choices.

1) Dumb code that works aka kludge.

The author is advocating kludge programming.

(I want to use this word distinctly from hacks, which are fewer and atleast clever)

I advocate this.

2) SQlite, Games

I advocate this too. Software that is meant to last, requires rigor.

My point is, the author is considering all programming to be engineering programming. It's not. And I do hate project managers that confuse the two.

I even concede that you can mixmatch the two (testing for eg). Why don't people see this middle ground ?

Reply on news.ycombinator.com