I think you’re both right. If you frame the original comment as “don’t write final production code without thorough modeling” it works both ways. If you want to counter with “well our non-final code always goes to production anyway!” You have a cultural problem that needs addressing.
> Examples include circuit board layout programs, finite element modeling, any engineered hardware product, entertainment (like computer games), or anything other than pure business, really.
"Don't write code" really means "prototype first for your potential users". So if your code won't have users/customers, then write away. But hardware and entertainment can absolutely have low-fi cheap prototypes.
This approach is designed to elicit learnings to make a better product that's cheaper and faster to build. Of course you can write code first, but my experience suggests that that's a slower and more expensive approach.
you don't know what's gonna make the final cut though. Stuff like language creation is super early on in the process at which point you're trying to engineer a system for success.
It makes sense because you don't know what you're gonna end up with and overshooting is better than missing.
I think this is a similar (though more annoying) issue to what we go through in engineering at times. Before coding, my workplace likes to draft up design documents that specify the what, the why, and (sometimes) the how of what we're about to do before we go and do it.
In a way it's like using Photoshop in that the nuances of the language don't really impact the plans at the time, though losing the prototyping can be annoying. But this metaphor does break down because I think the problem she illustrates is far worse.
A common misunderstanding about software creation is that code is the desired result. Hence, estimates more often than not try to predict how long it'll take to write the code that produces a desired outcome.
However, in the end, code is just a very detailed specification of the design that produces a desired outcome. There's a reason why production is called production, after all:
Therefore, equating code written by a software developer with the final result is a little like equating an architect's blueprint with a building that was built according to that blueprint. The fundamental difference between those disciplines, of course, is that with software development most of the manual (as in: non-automated) work is done once the code has been written, whereas with construction the by far largest part of the manual work involved happens after the architect has created the blueprint.
On one hand, this is a problem of perception. On the other hand, though, it's quite understandable that customers don't want to invest the better part of the budget upfront, not knowing if the design will meet the requirements.
This is where agile management methods come into play. Those can be misused or, indeed, abused, too, but the idea of eliminating waste and adapting early is a sound one.
I think you missed my point then. The goal isn't to reduce mistakes, although that is often a secondary benefit. My suggestion was to shift work habits to a form where they have ownership of design rather than ownership of code. Also, a key point was to front-load criticism to early in the development process rather than toward the end.
There's a difference between exploratory programming and the final deliverable.
I don't think the GP is suggesting 100% of spec must be completed before the first line of program code is written. I think the implication is that there should still be a dividing line between the design portion (made up of think, code, rethink, recode) and the production development portion (also made up of think, code, rethink, recode). The dividing line does not need to be months, but design as a phase of a project should be considered differently (since it has different priorities) than delivery.
that sounds like ignoring practice in favor of theory. when your boss asks you to build them something, you dont ask finer and more detailed questions until you have gotten them to write the code. i think its bad to let the lowest common denominator dictate our legislative policy- the lowest common denominator is going to fuck you over regardless.
So the reason is to
1. Create a prototype, and
2. Get respect from developers.
Re: #2—Let's reverse this, specifically for marketing.
Developers (and pretty much anyone) who know a little marketing can be harder to work with than those that believe they don't understand it. They over-rely on cliches and stereotypes without realizing it.
And what about the scenario where you end up with a person with limited technical knowledge micro-managing a tech worker? Not a good thing.
Re: #1—I find creating mock-ups shows functionality more accurately and in much, much less time than creating working prototypes.
I'm a business/marketing guy who loves coding. I usually avoid it because it's incredibly time-consuming to do even half-assed well, and you can re-use little of what you learn when it's just a one-off experience to creating something to show. (I realize that if you are always learning and creating things, your experience builds in more reusable ways.)
I totally get the argument. But in my experience it's rarely the first idea that you end up running with, or that will work on the market. It's generally significantly different project in the end if you're able to get to where the market is telling you to go.
This leads to the idea that unless the code is conceived well up front it's highly unlikely you're going to be able to learn from the market and adapt to what it's telling you if you're working with a bunch of ill conceived code from the get go.
Is there a middle ground between the Lean Startup crowd who say you should never write any code at the beginning versus op's view of a fully functional product? I'm pursuing a working prototype but am constantly being told by both camps that I'm doing too much or too little. I don't think wireframes are going to cut it but I don't want to spend every spare hour I have on what others have already said is a lonely and often monotonous existence.
But this also makes it difficult to give accurate estimates because you sometimes need to prototype 2,3 or even more designs to workout the
best option.
> writing code should be actually seen as part of the "thinking process".
Unfortunately most of the times leadership dont' see things this way. For them the tough work of thinking ends with architecture or another layer down. Then the engineers are responsible only for translating those designs into software just by typing away with a keyboard.
This leads to mismatch in delivery expectations between leadership and developers.
Exactly. This is ignoring the fact that code is a more useful blueprint than anything else for programs.
I'm sure if architects had the ability to magically conjure building materials out of thin air and try things in real life for free, architecture would involve a lot more trying and a lot less planning.
Of course, I'm sure the article is talking about people just rushing into production code without thought, and I get that is a problem. It's just when people make comparisons like that it can imply this horrendous future where we whiteboard program for months, which is just a terrible idea.
And not everything is a cold impersonal engineering decision. Programmers are people (really! we are!) and people like greenfields and blank canvases and fresh starts.
And I'd also submit that a team of talented developers almost certainly will make a superior product if they have the ability to use the original as a reference and resource. The saying "Pioneers get the arrows, settlers get the land" comes to mind.
Make the right decisions based on measuring and talking to people before you start building and waste time. Code is not progress. Decisions (based on facts) are progress.
Yeah I can understand that. I've worked with plenty of designers who can't code, and to my taste the only part that can be a little frustrating is when they don't accept that some great ideas really can't be built. But that said, I do think that negative is usually outweighed by the value of keeping the ideal in front of the reality...it's just they need to be sure to also help with what needs delivered in two weeks!
As sort of a joke, I've been on the flip side of that---especially with more enterprise-y Microsoft stack style dev teams---where I propose a design and am told it's impossible and I respond with a detailed explanation of how to build it within their constraints. I think they like that even less! :)
reply