How to Start a New Software Project
Вставка
- Опубліковано 23 лип 2024
- What's the best way to start a new software project? This is about more than only software project management or even software development. Starting a new project is exciting and scary at the same time. So if you are a software project manager, team leader, or software developer starting something new, here is some advice for you.
Software development is difficult to get right; so how do we start in a way that improves our chances of success? We need to organise ourselves and our work effectively, pick the right tools for the job, create code that is easy to work on and does what our users and customers need it to. We need to adopt a software engineering approach and an agile philosophy that allows us to do good work efficiently. Ultimately we need to figure out early if our ideas are any good and if they are useful and meaningful to the users of our system.
In this episode Dave Farley explores some of the best ways to start a software project to give you a better chance of success from the start and to steer us away from creating tomorrow's legacy systems today.
-------------------------------------------------------------------------------------
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses.
AND get Dave’s FREE guide on “How to Start a New Project” here ➡️ www.subscribepage.com/new-pro...
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Kindle ➡️ amzn.to/3DwdwT3
(Paperback version available soon)
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ www.equalexperts.com/
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley - Наука та технологія
This channel is such a breath of fresh air. I am actually excited for every new video, which is perhaps strange given the nature of the subject.
Also, a wonderful host who knows how to present information in a calm and clear way. Thank you so much!
Thank you 😊
Agreed. And its none technical enough to spam it to people that reeeeaaalllyyy need to watch it 😈
You're not wrong!!
Since software engineering is an intellectual creative endeavor, I get great satisfaction listening to folks who are as passionate as myself talk about how to do it better!
I agree, It is hard to find senior people to learn from that offer good perspective. I don't agree with him on every little thing but overall this is phenominal.
As a professional product owner in a scrum team I absolutely love your videos. "Small steps, reflection on the impact of those steps and adjusting if those steps aren't taking us closer to where we need to go." the essence of software delivery best practices without the marketing.
Thanks, I am pleased that you like them.
You're so inspiring man. I love how you talk about software!
This is a golden channel. It might just be me, but it's so rare to find experts with serious experience talk about this discipline at a higher level rather than most channels that seem to focus only on implementation details. These ideas feel like the real decider of successful projects. You're an inspiration, thank you!!
“It doesn’t matter how the buttons are” - one of my new favorite quotes. While working on a software team and a side project with another developer and reading the continuous delivery text book. It’s easy to see the pipeline and how it changes, so if anyone wants to learn faster give this method a try.
I’d have to watch this a few several times over to fully comprehend these frameworks he’s broken down.
And it seems practical and flexible enough to apply to varying sizes of consulting & startups software projects.
The videos that you guys make are so good and really engaging. How I'd love to work with people like you, people with really strong understanding and solid opinions about software engineering as a whole.
the absolute best channel on youtube about software development. No question.
Thank you for your support!
This is one of my favorite so far!!
What I've been using to counteract the burden of early design decisions is a ports and adapters architecture, after I read about how it was integral for a Netflix studio team to develop their workflow application while uncertain of the final shape of the data. But I've also found a lot of conflicting information on how that's implemented properly, so I'd love to hear about your experience with that kind of architecture in a future video if possible.
Owww this video really helped me. It’s been a while a was starting a project wanting to do everything right at the beginning. I have been studying all the possible technologies and stacks required. I planned to throughly research on the domain problem. I thought I would never start this project. Thank you for your advice in the form of this beautiful story☺️
Love your videos insights of software projects!!
I really enjoy your videos! Very easy to understand and very usefull! They are helping me a lot to improve my skills as a solo and group software dev. Thank you!!!
Glad to help!
Awesome videos as usual, i think the most interesting thing about this channel is that it focuses more on Design patterns, architecture and CD and the channel is named. I find myself explaining things i've never read to colleagues and end up recommending the source of course 👍 👍
So true, so important. Great video. Thank you.
This example reminds me one of my own. I had to build a system to collect audio SPL levels from 5 microphones in the audience of Rock in Rio 2017. Then those 5 measures should be concentrated and averaged to be sent to another service that would then render an animation based on these live measurements on the screen at the main stage. The result is a huge karaoke. I used some android devices to capture the sound and measure the SPL and send it to a server that would then calculate the average. The first release was done exactly with HTTP. It turns out it was good enough. The first day of the event ran with that version. I was able to deliver the UDP version for the second day. Until now I don't know if they decided to change or kept the HTTP version.
Thank you for sharing this. Really usefull and practical advices!
Glad it was helpful!
Love the channel, but at least 10% of why I return are Dave's T-shirts
Using abstraction to defer decisions is a key skill.
You sir have the best T-shirts... and tips
14:35 - one of the wisest observations and rules to keep in mind at all times
Nothing new, and yet illuminating. Great, simple advice, so much common sense. Listen and learn, people! Great talk, Dave!
Thanks
Sage advice as per! This matches what Kent Beck writes in XP Explained (2):
"The alternative to designing before implementing is designing after implementing".
"Further design takes place once the implementation is in place and the real constraints on the design are obvious".
"....the XP strategy is "design always" "
Wise words, thank you. Love the t-shirt.
Another great video 👍
It would be awesome to hear you go into a bit more details about the architecture, design decisions, and code for that high performance financial exchange.
Thanks for the video =)
GREAT T-shirt!!!
practical applications of agile principles in software development
Thank you
You rock! Great talk
Converging imprecise engineering towards strong assumptions as the project grows leads to more successful products than if it was the other way around.
Keen to hear your thoughts on database cd with tools like dbup ssdt
Im working on an ETL tool to handle edge cases in the company I work for that currently require expensive consultants.
I am planning to embark on a new project with lots of complexity. How do I prepare for it? I watched a few of videos from Continuous Delivery to get the juices flowing. I like the way you think, and you inspire me to create good clean products.
Oh no... 6:44 you're describing my thread safe shenanigans.
7:50
I like to say that every mistake is still a step forward.
Not trying at all is not taking a step.
Yes, I think that you have to risk mistakes to do good work.
The T-shirt is soooo appropriate
Amazing amount of wisdom being communicated. Just one small comment i think you mean http instead of html. Did you mean something specific about html? Perhaps you meant xml as a payload?
Good video. From my old world way of thinking, starting a Project normally meant some Business Analysis up front with some vague acceptance criteria and tests documented. In this video it sounds like you dive straight in and start developing to show some bare bones functionality. I get how the approach here works but what happens when the team members change and new members wonder how decisions were made in the past. Are the decision points recorded in the code ? Are Scope changes traceable ? Just asking the dumb questions because I never bothered to keep myself updated.
The simple answer is that the tests help to document decisions and the code. In reality, whatever the approach, I think that a lot of this kind of learning is cultural, and never effectivelt captured in documentation of any form. If EVERYONE disappears from a project, it is always an exercise in technical arheology to get new people up to speed.
However, I think that a working build and working tests are the best possible starting point, other than having other people available to ask "why did you do this?". Written docs are mostly a much poorer subtitute for tests that run and pass, and so are guaranteed to be in step with the code.
AWESOME shirt. :)
Thanks! 😁
Lean advocates would call this "fail fast"
Game developers would call it "create a vertical slice first"
How did you go about getting the requirement for speed at the start? Did you know how fast it had to be to be world beating, and if so how did you get that information?
Thanks for the video super interesting!
Yes we did research to find what market-makers saw as “good-enough” and “great”. They are the drivers for high performance in exchanges, because their algorithms depend on low, but even more importantly consistent, latency.
Please take the time for it to be another day. I'm curious and that SEDA story.
Most of my career has been spent maintaining an existing codebase, because that's what the budget holder is paying for. Any suggestions on how to apply these blue sky ideas there?
Excellent video. I cannot find your book. Can you put a link here to where I can buy it please.
There are links to my books in the descriptions of most of my videos, but not this one, sorry, here you go:
“Continuous Delivery Pipelines” - Dave Farley ➡️ leanpub.com/cd-pipelines
"Continuous Delivery", Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
What is your view on Scaled Agile Framework? I noticed that quite some of your ideas are reflected in that SAFe approach.
I am not a fan of SaFe. Martin Fowler calls it “Shitty Agile for Enterprises” I think I agree. I wrote about my thoughts here: www.davefarley.net/?p=337
SaFe - the agile waterfall.
Fantastic insights, and 100% usable. These principles are primary and profound. Thank you for sharing your great wisdom. Subscribed.
Excellent explenation. A good book outlining this topic (among many others) is "Code Complete" by Steve McConnell. It's a good read, I definitely recommend it for anyone interested in software architecture, development and project management in that regard.
Thanks for sharing!
hmm starting points should not start out wrong or you will get nothing but wrong until you change. Instead, I look for reasonable starts. Do we have an architecture? What technologies fit close enough from what we do know? Can we create models of the data, so we can get inside the problem? Can we identify the moving parts of the program? The first few coding sessions should be free of form and constraints and just brainstorm on the idea. Later we can define structures and start forming constraints.
I fell into a trap of building the new system from start to end without user feedback. It took us over a year before we released first version to users. I was working along a great domain expert who knows everything about the problem we tried to solve, but as a result we built system which was to complex for the normal user, which had much less knowledge about the domain than our expert. It was doing more than and expected more knowledge from the user.
The biggest mistake was that we didn't releas early and didn't have that feedback from our customers, it was internal system used by our coworkers. After release we have attempted to simplify the system reducing the amount of information user get, which was overwhelming for them. I left the company before we finished so I cannot tell if it was a success.
I'm stil wondering how using approach as in this video - realease early, get feedback, adjust - would affect the project, and I hope I would have a chance to build something similar in the future, applying lessons learnt from that project.
I am just about to kickstart a new project in my work, and it is good to hear that I've independently reached the same conclusion as you, who are clearly a master in the field.
Making the code easy to change is probably one of the most important properties any code can have.
Yes, I describe this in my new book as "managing complexity" but making the code easy to change is pretty much central to that.
Now here is something I get hung up on. Getting feedback from users. When development shows a preview of what something looks like to the users and the buttons aren't exactly right or it looks ugly, the users react really negatively. Then there is a political backlash to development that has to be managed. I haven't worked for any company that can handle conception demos and get feedback. I am sure smaller or tech companies can do this but mature organizations with employees that have been there 15-20 years don't handle it well. Any ideas on how to get better results?
My preference, where I can get away with it, is to do such demos with lo-fi prototypes. Don't try and show a partly functional version of the real thing, instead make it obvious that this is a model and not the real thing. My experience has been that people are fine with that, even down to using sketches on whiteboards or pieces of paper. You can have sensible conversations about usability and so on, without getting lost in dumb arguments about the colour of a button or "that text should be 2px to the right" kind of things.
Nice T-shirt
Hi, I'm a student, what do you mean by "Thread"? Thanks for anyone who can answer :)
docs.microsoft.com/en-us/windows/win32/procthread/processes-and-threads#:~:text=A%20process%2C%20in%20the%20simplest,being%20executed%20by%20another%20thread.
less interested by this, but agree to it. This lot of common sens.
Most software projects that fail do so because people spent time reading books about managing projects and having great theoretical arguments when they should have been doing the work.
particle.js in the background
God will this ever end. Years and years of this way vs that way and methodologies and frameworks and aaaargh! It stopped being fun so long ago.
I don't think the industry will go back to basics unless they get a healthy paycheck out of it.
Personally glad to be a part of the old guard who still thinks about software engineering at an atomic level instead of being stuck in framework hell.
@@SimGunther yes but we're in a minority and working with people who are zealouts instead of engineers is taxing
I think I have accidentally created a legacy system on day.. what..20? Haha nice..
Liked the video. But I have downvoted the video because there were few too many shameless plugs.
Because of our many past sins, my team has the following two directives that have never failed us:
Do nothing but the needful.
Trust nothing, and Mr. T.
And yer video here says more or less the same things. Except that you don't mention Mr. T.
Dave, I hereby accuse you of being a "Theory of Constraints" advocate.
My new favorite software channel on UA-cam