Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
There is also explorative programming. Doesn’t need to be broken code.
Bit yes, the different styles will clash in a company. -
Vibing I'm 100% first one. Private projects the second one. Professionally company depended I guess.
-
Tounai15974d@Lensflare to me explorative programming is the same as broken, but I prefer this way rather than specing everything.
-
Yup, PM wants 1 everyone else does 2, he still cries about it. I'm sure we'll all be replaced slowly, as they don't fire him, no matter how many times people complain...
-
hjk10155363dI don't think it's controversial, I think it's just not true. Different situations require different approaches. I've mixed the to up quite a bit. Had to really push for 1. at times because dumbasses like to use agile as a magic keyword to not think things through and not supply enough info or content to go beyond 2 days of development.
-
Or you can do a little bit of both. Works best for my use cases.
Define high-level plans in advance with contract layers set or partially set, define epics and their DoDs, assume they will work, and split all of them into tasks, divide across teams. Let them figure out ["carve out"] the solutions. Then in the end make final adjustments to both impl and contracts and voila. All teams were creating value, client had a pretty good definition of what's going to happen, with some RnD DoDs have been achieved. -
yeah I had architects and their plans often were not gonna be the literal solution
a spec is nice but it's not necessarily the best or even a workable design. it's a rough direction to get you started
(and then I went back and changed the architecture drawings to be how the code actually was)
Might be controversial here, but to me there’s two types of software engineers
- those who like to spec everything before, fully document their approach
- those who start with rough, broken code and carve the stone through time
And I believe it’s two irreconcilable styles, so when both are present in a company, it necessarily ends up with a war
rant