One well established wisdom of the “LEAN” methodology is the importance to validate. A lot of methods for this exists that does not require any code but sometimes it may be easier and faster to code a small segment of the product that needs validation, knowing full well that this code may not partially or wholly be reusable again.
This sounds like a very inefficient idea. After all we shouldn’t touch code until we have validated in other ways. But to be honest the practice of writing code, especially one that we don’t expect to scale to large users is not very difficult. Much of the time of production level code is spent on the reviews and details that will make sure the code is secure, well integrated, fast and scalable.
We should however make a habit of writing code that is for validation and experimentation only which does not need to be any of these four things (except for maybe secure, depending on whether we are using any private and real data).
Much of our idea of what building software is that we are making a monolithic structure that once settled is part of the final work. Even when we make corrections or changes we are still working on the “production code” which is the user facing part of our website. We should however make a cultural shift and be comfortable thinking that up to some 30% of the code our engineers produce may be for experimental and discovery projects which will likely be thrown away.
This is not a waste of resources. I strongly believe that we focus too much of our cost calculations in software development on deliverable end products. But building a software is more than the end product, and especially so for teams that take the time to research, experiment and validate their ideas.
When is building code necessary to test an idea? This is a key question and I’ll try to answer with something other than “it depends”.
Validation should start first with research that can be done without any product work, meaning not building mockups or code yet. This research includes market research, talking with clients, getting information about user flows and habits that will inform their use of the code. The next step would be visualizing the implementation through mockups and inviting users to comment on those; which will elicit much more precise reactions.
Often though some ideas will need interactivity or complex steps. In these cases talking the user through a process or showing sequential mockups will not give the entire picture. It would be better if they could in fact play with the concept on the screen.
An area where this matters a lot is likely new UI experiences that include dragging and movement as well as interactions with mouse and hand movements. These are the types of cases where the interaction is not easy to describe to users and describing will give you potentially flawed data.
Another use case is when user input can’t exactly be trusted. It’s generally better to let users try something than simply ask them “does this make sense” or “would you click that”. Until given the actual tools to interact with we can’t measure whether users will actually do these. A significant benefit of writing the code is that we can release the idea to users without actively observing them and record their actions.
Another reason it would make sense to code some segment of our app to test is to connect it to their data. If our app is data intensive, whether a specific UI change or tool would be useful to them would require them looking at their own data. Designers showing users hypothetical and out of context pretty graphs is not going to help users make a good judgement on whether something is useful. Because your data layer is separate from your front end, you can connect your data to experimental uses as well (being mindful of security again).
An important missing part of this equation is handling engineering expectations. If your company only ever praises and validates code that is merged into production for general release then your engineers won’t want to work on code that will be “thrown away”. You need to make sure that your entire team, from engineers to managers, understand the value of validation and that code produced for this effort gives you more reliable data and saves you engineering time down the line.