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.
I agree with what you're saying here. Except what you're saying is the antithesis of what the article is saying.
> The mistake you're falling into is that you're assuming that this means that _everything_ has to be defined up front. But nobody's actually saying that.
This article is entirely focused on the idea that sketching and wireframes are bad ideas. I fundamentally disagree with that. From the article:
> The temptation is to jump straight into building mode, to write code or build wireframes or sketch drafts of what you want to create. The better idea is to write your idea down as a way to think it through and improve upon it. Then, when you start building, you’ll know exactly what to build, and why, and you’ll have pre-written documentation at launch.
Yeah the farther I have gotten in my career, the more I ascribe to a disposable code philosophy. Of course it doesn't mean that it's a balance, and there's a time and a place for structure and thinking about design, but that is almost always done better when you have a working prototype than when you're starting something from scratch.
The arguments expressed in article actually defeat itself (article is self-contradictory)...
1) Getting attached to wireframes (or any other design concept) would be detrimental (OK... let's agree)
2) Wireframes are ugly (Well... that's actually good, so you wouldn't get attached to them?)
3) It would be better to start designing and coding on the target environment right away...
Well wait a minute, don't you get that by doing (3), you will get attached to your first iteration design, and will not realize when it's time to throw it away, and reset/pivot with a new approach?
I don't know that there are many people in industry who can't code or who don't care. I think there are lots of people who may not share in the peculiarities of my opinions, or who need every minute to deliver requirements, and who feel that "working" is sufficient.
Is that wrong? I'm hesitant to say that it is. We're optimizing different things. Their approach is better in some situations - startups need to ship features fast, and if you don't have to touch the code again, it doesn't need to look good, it just needs to work. My method is optimized for sustaining engineering by adding up-front engineering time, which startup engineers may not have.
I think the most appropriate thing is to realize what situation you're in, and make value judgements there. If speed is required, optimize for speed. If sustainment is required, optimize for sustainment.
I agree with your point. IMO its all about communication. Currently, I am building a product with somebody and between the both of us the wireframe is more than sufficient. But, after 2 weeks of coding we started showing it to our friends and instantly we could see the ranges of communication errors - some got it despite the 'bad ui', some just could Not look beyond the ui fails, some were kinda sorta struggling.
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.
I disagree. It's sure not a cliché. I've often seen programmers gold plating their solutions. As a programmer myself I understand that very well. But most of the time, a half backed solution will unlock many things that are more important than the code. With some prototype level code, you can already test ideas, show things to a customer, start integrating with others, etc. And afterwards, you have the opportunity to decide if optimizing for speed/space is a worthy trade off, or if optimizing at all is important.
Now, this won't work for any kind of industry. Right now i'm in the business/government stuff. There, prototyping is much more important than speed of code. When I was in the gaming industry, the lack of speed was most of the time a technical debt. But even then, having my code working was much more important to the overall team effort than my code being fast.
So instead of your chart, I prefer : 1/ Code is working, 2/ Code is correct 3/ check for other priorities 4/ optimize as needed.
As for what you're expected to do and company value, my experience is that not so many people understand the link between actual code and company value (esp. in the top management where I sit regularly). You'd be surprised to see how much a deadline is more important than a fully working/optimized program ('cos for example the deadline is a trigger for a enormous change in the organization you work for (although we know the lack of speed in the code will have negative impact on dozens of end users))
so, well, it depeends :-) but still, a word of caution sound right to me :-)
The issue is, people rarely build the right product on the first try. Your reasoning here assumes that the thing you've spent time building well was the right thing to build. It's worth getting things out quickly initially to find out if anybody wants it. You don't want to compromise the experience of your product (external). Thus it's best to sacrifice features and reduce complexity, in order to test ideas and the quality of product experience. Writing code is just a means to this end.
I've also seen people do a ton of up front design, only for things to fall apart quickly during the implementation. I'm still largely a proponent of writing code sooner rather than later. Iterative development. Prove out concepts in isolation along the way. Rewrite and integrate as appropriate. But obviously you've got to do some upfront work, otherwise you might write custom software for things which have off the shelf solutions.
I agree. Perhaps using wireframes was not the best analogy. I studied computer science and spent quite a few years as a developer, both inheriting code bases, and building my own, so i do appreciate code thats built to scale! (though to be honest, mine rarely was...)
I totally disagree, get basic stuff done by the designer, but I find it completely changes as programming happens. You figure out things won't work the way you thought they should, you figure out better ways, etc. Get wireframes down, so you don't spend thousands on designers, and then realise you have to spend thousands more.
I agree that I should be looking for people who produce quality work, but I also think there's some flexibility to the 'interchangeable pieces' part of the argument.
Here's the thing: Building anything ends up being a very iterative process. From my personal experience, by the time one moves from the prototype/beta phase upwards of 90% of the original code/design base is thrown away, redone, etc. Since what I'm really looking for here is the first-cut that allows for the validation of the idea and the on-boarding of the first few (hundred-)thousand users, I think there could be some advantages to a little shorter-term thinking; if-and-only-if that means I'm able to deliver that first cut to market sooner than if I were to focus on the stability of the team upfront.
Don't get me wrong, I'm still wavering on my opinion of this (hence this entire thread). But I am really enjoying / appreciating the various methodologies.
> 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.
Personally, I'd say always wireframe / sketch before coding.
The reason behind this is the interface is what the users see and use. Your app's design (from a UI / UX perspective) will almost certainly come out better if you spend some time upfront on design.
As a bonus, you'll likely write less code since you'll know exactly what you're building. Without at least a (revised) sketch in place, you may end up unnecessarily generalizing methods / classes, or adding stuff that you end up not needing later.
Anyway, that's just my opinion. I at least do some sketches, with revisions, before starting an app.
Pretty good list but I think the author contradicts the notion and importance of iteration. No design doc and no code base is free from changes and improvements, particularly in startups. If you can't deal with changes, you probably should go work for an enterprise company where you spend half your time blowing hot air across the table. You can't just write once and leave it be, the problem with design mockups and wireframes is that they don't really encapsulate the element of interactivity, and certainly lack customer feedback.
I also think designers and developers are very much alike even though we often bang heads. It's a creative process to write code, and I think a lot of people outside the circle don't appreciate how mentally draining "creation" really is.
Mhh for me it is always a combination of the two. I like making a good high level plan, but for certain problems it is better to make the plan as you go, because you can't fully understand the shape of the problem and the potential solutions as you start. Sure maybe that means your first code sucks and is a prototype that should be replaced, but if you are aware of that and don't pretend otherwise I don't see why this wouldn't be okay.
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.
I don't get great results myself from diving into coding immediately. I personally get better results if I have some storyboards, workflows, ins/outs, etc. identified and worked-over first.
But when I do get down to writing code, it very much takes an evolutionary path. Typically the first thing I start writing is bloated, inefficient, or otherwise suboptimal in a variety of ways. Mostly it's to get the relationships between concepts established and start modeling the process.
Once I have something that starts looking like it'll work, then I sort of take the sculptor's approach and start taking away everything that isn't the program I want.
So yeah, a fair amount of planning, but the first draft of anything I write, really, code or otherwise, is something for me, myself, to respond to. Then I keep working it over until it wouldn't annoy me if I was someone else picking it up cold.
reply