Post AMBOevPd0IKRBwBMGW by paoloredaelli@mastodon.uno
(DIR) More posts by paoloredaelli@mastodon.uno
(DIR) Post #AMAuLM4nA2nBTJBkS8 by amolith@nixnet.social
2022-08-04T05:47:23.402891Z
1 likes, 6 repeats
You own a small company with one employee (you)Clients wants company to take on a big project, they describe what they're looking for, you give ballpark "won't be less than this" estimate, and they're happy to pay whatever you charge, so you agreeNow you have to start planning things out.You mention the possibility of helping to a friend, he expresses interest, and knowing that he's a better programmer and his experience would be very valuable, you add him on and decide to work on it as a pair. But what software dev process do you use? Hack at it till it works? Test-driven development? Feature-driven? Spiral? RAD? XP? Waterfall?(I am asking for advice)
(DIR) Post #AMAv2FvXtnvCqvJvLE by LaCrecerelle@digipres.club
2022-08-04T05:48:39Z
1 likes, 0 repeats
@amolith I'm a big fan of 'hack at it until it works' with very very frequent git pushes to get the MVP/PC, then going back and tidying, documenting, and testing.
(DIR) Post #AMAwOa5vhIc7j4O2M4 by piggo@piggo.space
2022-08-04T06:10:24.597600Z
2 likes, 0 repeats
@LaCrecerelle @amolith yes same, get it working, then clean up git history if needed, add unit tests. Pure TDD ime just gets you messy code, but tests are important as it grows. Writing tests too early will mean constant updating of tests if you need to change something, I'm not really a fan of that
(DIR) Post #AMAwZ9cAUQaimjVX2e by cregox@talk.ahoxus.org
2022-08-04T06:10:38.461316Z
0 likes, 0 repeats
@s8n @amolith agreed.but if you look for future growth in any way, and you're both comfortable with test driven, do go at least that far!
(DIR) Post #AMB411C45kimSHX21o by ilja@ilja.space
2022-08-04T07:35:42.575217Z
2 likes, 0 repeats
@amolith waterfall => NoTest-driven => That's more to do with how you personally write your software rather than a processWhere I work the typical approach these days is make an mvp, show it to the client, take feedback into account and go from there. And the moment you have something that can run, run it and improve from there depending on needs, resources and priorities.
(DIR) Post #AMBIP0VNhZFOd0tqcK by xarvos@nixnet.social
2022-08-04T10:17:00.587419Z
1 likes, 0 repeats
@amolith just hack at it till it works is what i would do :blobcatgooglytrash:
(DIR) Post #AMBOevPd0IKRBwBMGW by paoloredaelli@mastodon.uno
2022-08-04T10:44:23Z
1 likes, 0 repeats
@amolithSpaghetticode 😜Seriously, a mix of feature driven and test driven. Often walking a mile in their shoes (I.e. spending some time actually doing their work) is really highlighting
(DIR) Post #AMBOk1I6Zg4Ys75oPY by toychicken@mastodon.social
2022-08-04T07:49:50Z
1 likes, 0 repeats
@amolith you don't need a work mgmt framework for two people. It's just unnecessary overhead at this point. Find a good, frequent cadence for syncing up with your friend, and ask yourselves occasionally if it's still working for you both, and tweak accordingly.Similarly, put work in progress in front of the client frequently (I'd start with something like every two weeks). Check you're all happy with that, and adapt to suit everyone's needs...
(DIR) Post #AMBOk1jOwBuIElrbxQ by toychicken@mastodon.social
2022-08-04T07:50:04Z
1 likes, 0 repeats
@amolith ...You've probably got lots of things to do, so focus on getting one thing 100% done first, rather than a few things to 80%. In terms of testing, my principle is usually:* Make it work (hacky is fine)* Make it right (add tests and documentation)* Make it better (optimize and refine)I've been working with these basic rules for almost 30 years, from solo projects to big enterprise jobs. It works for me. 😁
(DIR) Post #AMBOoV8TYRYKakj2zw by fishidwardrobe@mastodon.social
2022-08-04T07:06:15Z
1 likes, 0 repeats
@amolith These are not all mutually exclusive. You're too small for waterfall to work, if it ever really did; you'll need to work in small iterative steps. You will need tests, or you'll end up breaking more than you fix each iteration. As for the rest -- everyone has their own thing that works for them. No rules.
(DIR) Post #AMBOpe8FakYkmcAN0K by fiskfan1999@nixnet.social
2022-08-04T05:59:39.011261Z
1 likes, 0 repeats
@amolith hmm i would pick test-driven because having as close as possible to 100% test coverage right out of the gate could be reassuring to your company. this also might depend on the project itself though.
(DIR) Post #AMBOxaWiscTNuzOrSK by LaCrecerelle@digipres.club
2022-08-04T06:18:38Z
1 likes, 0 repeats
@piggo @amolith the idea that you must always start with TDD is a corporate phallacy IMHO - perpetuated by middle managers who are too afraid of magic code that they can't clearly oversee.The best pace of development and innovation comes from hacking around and then testing/documenting once you're past the MVP and have to think about feature development etc.
(DIR) Post #AMBpnogy3ZbfiXkzg0 by vertigo@hackers.town
2022-08-04T16:07:10Z
1 likes, 0 repeats
@amolith I have had excellent experience with XP.However, it's not for everyone. Some people don't like the idea of two people hacking at the same keyboard.But, every time I've done it, it has been a resounding success. Code gets written much faster than if I've tried to do it alone. The instantaneous feedback kept me and my partner on track for longer, and the built-in inclusion of TDD into the process ensures high code quality.
(DIR) Post #AMBw5fTZexsW4WO64m by Cambria@fosstodon.org
2022-08-04T17:41:11Z
1 likes, 0 repeats
@amolith a quick planning session where you scope out the work and divide it into tickets, git with feature branches for each ticket, and semi regular check ins will go a long way even on a two-person project.
(DIR) Post #AMCnjZETaTnXrVEi6y by mikeburns@mastodon.technology
2022-08-05T00:15:28Z
1 likes, 0 repeats
@amolith if you're actually pair programming, I do recommend ping-pong.If you're working in a programming language that is tough to wrangle (Ruby, JavaScript, Python, etc.), that's TDD. If you're in a language that has more static help (Java, Rust, Haskell, etc.) then you could alternate interface and implementation.
(DIR) Post #AMFMANWpccvgaC7DW4 by duponin@udongein.xyz
2022-08-06T09:18:01.285951Z
1 likes, 0 repeats
@LaCrecerelle @piggo @amolith TDD is interesting once project start is settled and you wish to make it resilient and annoyed by always testing sane things again and again to be sure you didn’t broke something without noticing it
(DIR) Post #AMFOTWjno3fsYTROOO by piggo@piggo.space
2022-08-06T09:43:53.953057Z
2 likes, 0 repeats
@duponin @LaCrecerelle @amolith i generally add tests after fixing a bug, to verify it's really fixed. the tests just keep being added over time. of course theres also tests for like, utility functions that are used everywhere
(DIR) Post #AMFkYFTJcsPLRfNyr2 by tost@mk.toast.cafe
2022-08-06T13:51:05.248Z
1 likes, 0 repeats
@amolith@nixnet.social I'm bad at this stuff because I only have one mode of developmenthypomania attack until it is done
(DIR) Post #AMFkpF9w2dApOmQNyi by avocatto@mk.paritybit.ca
2022-08-06T13:52:58.072Z
1 likes, 0 repeats
@amolith@nixnet.social I tend to like "Make an MVP while documenting all the hacky/needs improvement stuff (with FIXME comments or whatever you want) and then going back and cleaning things up.That way you can get something working quickly and iterate through improvements.But first it's a good idea to lay everything out. Don't just start coding, but make some kind of document that details what each part of the program needs to do, what kind of ui/api it needs to have, that kind of thing.
(DIR) Post #AMFkvQsVNrOhTvDt7g by khaosgrille@fedi.absturztau.be
2022-08-06T13:55:27.256007Z
0 likes, 0 repeats
@amolith neovim. i mostly use insert mode and sometimes visual mode