Building software from scratch, the user-centric approach (Event date: 11/24)

[maggiechu26]

Event Updates

Veerle will be sharing more on this topic in a 45 minutes virtual event on November 24th.
Sign up now to attend the live event and receive the recording.

Details

• If you’re a developer, you are mostly likely able to build some sort of software. However, building software isn’t enough if you want the softwares to be meaningful and helpful to the end user.
• Before you even start to think about implementation, you should start with your users' needs first. Coding should not be involved in this process.
• Focus of the talk: I’ll guide you through the steps to effectively build the right software for your users: from the initial process of getting to know your users' needs, to shaping and validating your ideas using wireframes, and the subsequent iteration process when you're adding and optimizing features.

Speaker

Veerle van Leemput - GitHub, LinkedIn

Veerle is an entrepreneur and Data Scientist who gets excited about data and programming. She is Managing Director and Head of Data Science at Analytic Health, a UK-based company that develops intelligent and accessible technology which gives organisations the tools they need to accelerate innovation in healthcare. With a Master’s Degree in Data Science and multiple years of experience in the pharmaceutical market, she develops healthcare applications in R (Shiny), Vue.js and Node.js.

What the speaker would like to know

• What else would you like to know about this topic?
• What would you want to take away from this talk?
• Do you already have a standard approach when building new software?
• Do you think this would be applicable to you or your team?

Share your thoughts

1. Upvote ⬆️ if you're interested in this topic
2. Leave a comment to:
   • Answer the questions above
   • Share other suggestions
   • Or simply give some encouragement to the speaker! ✨

[vaibhavgarg90]

In addition to all this, some details reg what mistakes newbie developers usually make can be shared.
Also, how to change the mindset from getting the software/product/feature work to asking all the right questions before jumping into implementation.

[hypebright]

Great suggestion, thank you! If anybody wants to share newbie dev mistakes, please share them here so I can collect a couple besides my own :)

[hellosimplerick]

This should probably be entitled "Step back from the keyboard until you do this"

Then point out/emphasize finding the problem before making the solution. Listen to customers and look beyond the words to see what the underlying message/concern/opportunity is. Solve a problem is so much more that whacking on a keyboard. Getting all fancy about PRD, MRD, and this and that is a surefire way to miss the macro point of learning the customer's pain points beyond even what they think it is.

That's a course worth paying for.

[jenniferfu0811]

I love this. Do you think you could share more about how you do this? Do you work with user researchers and UX designers to pinpoint customers' pain points first or do you or your team have a way of finding users' painpoints independently?

[hellosimplerick]

I try to keep things very (very basic) and stay far away from UX designers/researchers until I have the basics down. I'm assuming this whole Codementor exercise is to make me (the end user of Codementor) better. So, I can give you an example:

I have a collection of 82,000 digital photos, not including hundreds of old analog photos from family as well as negatives, slides, etc. from 'the old days/country.' Like you, and others, our families age. Great great grandma who could identify Uncle Sid from when he was at Elis Island (in the photo), has passed away. Grandma, kinda remembers. So, that photo, named, DSC0001.JPG after being scanned in is just that, some photo. What people need is a way to get the older generation to provide context, identifications, timing, etc. Whatever they can so that the family history is not lost. This came from sitting with a friend whose grandmother had died and as part of cleaning up, a box of old photos was found. Her mom knew a bit and they had an uncle who could help, a bit.

I asked: What would you like. She said, I'd like to put pictures in front of my Mom/Uncle and capture both the data (who/what/where/when) and some context audio. She pointed me to a video where they had interviewed Werner Kempler of Hogans Hero fame. The video was him going through his life, talking about all he had done, people, etc. along with old pictures. She said "That". From there, I've been building an app to do this and after talking with others who missed out with elder generations, I got the need. After that, yes, a UI/UX person is vital because the database and data entry/storage is trivial. How to engage with someone who is in their 90s, not tech, and is not about to sit at a PC "tagging" and "renaming" photos, is much different from me engaging with you.

This is my point about stepping away from the keyboard and focus on the issue/problem/pain point, and until you have that in your head, paper/pen is a key tool. On the app above, it is now being framed in Figma and then will be an intern's process to refine the user stories and a UX/UI person to make something that can then be coded.

Wow, long winded, sorry. I hope this answered your question.

Rick

[hypebright]

Great and beautiful story Rick, thanks for sharing that. The way you're laying out your specific use case makes me think about adding a more personal story to a presentation about this as well. Not necessarily talking about software that you produce for a company or a client- every app (small or large) can benefit from good software dev principles and starting with the basis instead of jumping into coding.

[fbuireu]

Do you already have a standard approach when building new software?

I mostly do, however, the technical solution always relies on the kind of project my company wants to develop. I have a strong opinion that the technology must always adapt to the business needs, not otherwise. If it's not that way, the projects tends to scale lower and be less maintainable than if you choose the proper technology for the proper project. Legacy code appears quite often and code refactors became a nightmare.

I feel that most of my fellow developer's twists and bend the frameworks or the programming languages in order adapt them to the business/technical needs (because they feel comfortable with them) and it may not be suitable in all situations. If a project is not suitable for X technology because of its intrinsic behavior, it's an extremely bad choice to develop it using that technology. We are constantly learning so choosing a new programming language to develop a new project must be something not to be afraid of. In fact, it should be something to be proud of. So yes, having a standard approach is an excellent option but it must not be the only-path solution for all scenarios or use-cases.

[hellosimplerick]

I concur with understanding a number of frameworks for functionality and true/proper applicability. I am reminded of my early days at Microsoft when office products were sold separately. Word, Excel, etc. We found a number of people who took column A in excel, dragged it across the screen to get whatever the number of characters were default at the time, and used it to take notes, write basics, to avoid buying word. That stuck with me for all these years so I avoid trying to do everything in Python or JS or whatever and, first, figure out what the problem/solution set is and then find the appropriate framework without falling into the I know Python so do it in Django trap with a simple HTML template would do it.

[hypebright]

I'm with you when you say that technology must adapt to the business needs. But what do you do if you're deep into a large project (with an already chosen framework) and the business asks for new features? Features that are actually not suitable for the chosen framework?

[hellosimplerick]

There are always trade-offs, for sure. That is why civilians (aka business people) get trained (when I'm involved/asked) on:

• Strategy. Where are you going? What's the "forget the tech" vision. Articulate, refine, rinse -n- repeat. And keep doing it, without tech talk until there is alignment/excitement on where're you're going. The more invested in step one, the better.
• Road map. Comes out of strategy. Block it into chunks so there is a clear alignment and understanding of features and timeframe.
• Technical Debt. Bean Counters, Civilians have zero concept of what this phrase means and what the short/long term impact is associated with it. Teach them so they can ask "what will this cost" in terms of technical debt/tradeoffs. This starts at the top and ignoring is at the company's peril.
• If I can make Excel turn into a word processor, I can make React, Flutter, Django, etc. do 'anything'. If I'm sensitive to the strategy, direction and debt risk (as the business person), I'm less likely to blindly ask for the feature that sends the project into modification hell without knowing the true cost/impact.

Almost 80% of projects get bad outcomes because Geeks head for the keyboard and Civilians head for a 30 minute hand waving exercise with both failing to align. I've seen the movie a million times. Never ends well.

[fbuireu]

I'm with you when you say that technology must adapt to the business needs. But what do you do if you're deep into a large project (with an already chosen framework) and the business asks for new features? Features that are actually not suitable for the chosen framework?

I completely agree with @hellosimplerick. It's our duty to expose and reveal weaknesses of the code (or on larger scales a project) and propose a way of refactoring to decrease this legacy code. And it's PO/PM managers decide whether or not act accordingly to accept it or not, keeping in mind that, depending on the implementation, all code is meant to become legacy, but the idea is to create an architecture that protects the code (Solid, DDD, Clean Architecture, etc - which usually may seem backend concepts but they can also be applied to front-end side-) to became legacy at time -1.

This also applies to the technical debt that is also meant to appear sooner or later, the idea is always to create a scalable structure that makes the refactor of the legacy code easier to apply.

Answering more specifically to @hypebright: as I said, I personally think that you have to expose the weaknesses of the project (in this case the bad choice of the framework) and provide a suitable alternative. There's no manager in any company that wants to waste 2h to change the color of a button (reducing complexity to absurdity).

I hope I answered your question but if I don't, please don't hesitate to ask me for personal experiences or further details 😄

[hypebright]

Definitely true @fbuireu whenever there are weaknesses of the project that get in the way of developing it further (aka scale) you need to expose those weaknesses and provide an alternative. Communication is key.

If I speak for myself, my company is a start-up. Very small team. No PO/PM managers. Just me (as developer myself and acting as PO/PM, tech lead, everything basically) and our small team of developers. There are trade-offs in such a setting. We have very limited resources (time, money, people). Sometimes we don't even know if our software gets any further than the MVP stage. So while we're doing our absolute best to choose the best framework, we're not going to crack nuts with a sledgehammer. Simply because we can't afford sledgehammers. As the project grows we scope it out further and may switch from framework. For example, we started a project with a R Shiny application (quick to set up, we had the skills in-house) but switched later to Node/Vue as the project grew more into a CRM like application. As long as you recognize the weaknesses of your framework, and recognize when your framework fails for the (changing!) goal, you will make the right choices when the time is right.

@hellosimplerick companies who are just getting starting with proper software (yes they still exist), and are moving from Excel to a professional custom made application, most often want to start with something very small and simple. They need to get their colleagues on board after all. If they then got a taste of what it can mean for them, they start thinking and the requirements can change 180 degrees. Sometimes it means you need to change your software completely. But that's exactly what user-centric means- thinking along and growing with your users. Help them to quickly (with a low budget) promote software in order to get more resources to take the software to another level.

That being said, I think there's also some difference between B2C and B2B software development- as with B2B the dynamics (and type of users) are completely different. Interesting discussion as well :).

[tc6899]

Sounds like a great topic. I'm still a noob learming, but want to develop a commercially successful learning platform for schoolkids. I've been designing the core concepts, but I'd love to know more about:

• choosing which features to start with for the MVP
• how to identify vital anything I've missed
• how to validate as much as possible before starting coding
• how to conduct user interviews without leading them or having biased questions
• software that you think is most efficient for the task at hand - wireframing, feedback etc. Also most reviews/comparisons go on about price, and the cost is always so small it's insulting compared to the time it could save. Time is WAY more important to me.
• is no-code validation just a waste of time when you have to learn a new system, and eventually end up coding anyway (I'm a one man operation)
  I've never done this before, and this sounds like it could massively help me. Thanks!!!

[jenniferfu0811]

The questions, discussions, and personal experience shared in this thread were very insightful and practical. Finding the right balance between staying flexible yet sticking to best practices is no easy feat. Some of the topics that were covered included:

• Getting user’s basic pain points down before jumping into solutions
• Being flexible and adaptable with frameworks, depending on users’ needs
• Revealing code and framework weaknesses to make sure the structure is scalable

@hypebright has shared some of her own experience, questions, and thoughts in the thread, and we’re happy that she’ll be sharing more in a 45 minutes virtual event on November 24th.

Here’s the link to register for the event! Please bring your questions with you to the Q&A so we can all continue the discussion at the event.

If you can’t make it, register so we can send you the recording afterwards 🙂

Hope to see you all soon.

P.S. @Anita-ihuman will also be sharing her talk, “Getting into tech without a Computer Science degree,” on November 16th. Here’s the link to register for Anita’s talk.