4 ms·

Other good nothings: Can you check in even a tiny change to the source-code repository? A new project's first commit often triggers a slew of politics: wait, y

by sowbug 3y ago

Other good nothings: Can you check in even a tiny change to the source-code repository? A new project's first commit often triggers a slew of politics: wait, you're building what? Where's your design? Who approved this? Why are you naming it this and not that? We already built this; why are you building a second one? What's your installer story? For installable software, do you know how to produce the installer for it? Too often the installer work is left until just before launch, at which point it's way too late. For a service, do you know how to deploy anywhere but localhost so your team can start doing internal demos? Can anyone besides you build your hello world code? The release team often has their way of doing things, and it's not what Visual Studio spits out from its new-project template. Might as well integrate early, rather than wasting time solving problems for a build system you were never going to use.

scruple 3y ago
That all sounds wildly dysfunctional. I've worked in startups with single digit engineering teams, up to massive corporations with tens of thousands of employees. I have never faced this sort of bullshit. I'm not even sure how I would respond to someone asking me, "wait, you're building what? Where's your design? Who approved this? Why are you naming it this and not that? We already built this; why are you building a second one?" but I can be sure that whatever came out of my mouth would be step 0 of finding a new place to work.
- valleyer 3y ago
  Sure, some of that sounds like "red tape". But avoiding needlessly duplicated functionality seems like a rather noble goal to me, one that can save everyone a great deal of maintenance effort in the future.
  - scruple 3y ago
    It's making blanket assumptions that a) the question asker knows better, and b) that no one bothered to think of any of this to begin with. That's not a functional way to approach organizational problems like teams building the wrong thing. Never mind that, I'd wager oftentimes the IC standing up a new repo isn't the right tree to bark up anyway. FWIW, I personally start new projects with a Software Design Intent document that explains what we're attempting to do and why with full disclaimers about what we do and don't currently know. Maybe I've just managed to hedge these people out.
    - sowbug 3y ago
      > Software Design Intent document That's great. But having written it doesn't mean that everyone has read it. And not everyone who has read it will agree with it. Or maybe the person who you thought would champion it has left the company. Or maybe the world has changed since you wrote it. You've probably heard the expression "no business plan survives first contact with customers." A corollary, in anything but an extremely top-down organization, is that version 1 of your planning doc is unlikely to perfectly describe the final product. > a) the question asker knows better, and b) that no one bothered to think of any of this to begin with Eh, that's assuming a fair amount of antagonism on both sides. Most people are reasonable and rational, and after the initial "WTF? Are you crazy?" handshaking, everyone can get on the same page. But that process takes time. If your first contact with a downstream person/team/group is right before your 1.0 is supposed to ship, then you're more likely to treat them as a roadblock. If you instead involve them early, get the WTF moments out of the way, and take the time to develop a relationship, then you've turned a potential roadblock into a stakeholder and advocate, and your SDI becomes a true representation of consensus, rather than a bludgeon.
      - scruple 3y ago
        > That's great. But having written it doesn't mean that everyone has read it. It's just describing the intention of the team at the onset. Nothing more. I will not update this document once things get really rolling, that's why we have design documents elsewhere. What I personally do with this thing is I put a checklist of "approvers" at the bottom and I send an e-mail to them all asking them to review it and give their nod of approval or otherwise. FWIW I'm in agreement with everything else you're saying here, though.
    - RetroTechie 3y ago
      > Software Design Intent document Sounds like a good way to nip the creative aspect in the bud. Sure, if a client comes to a software vendor with a clear plan, draw up good specs, requirements etc. before doing any design (or coding). Or code a quick 'n dirty proof of concept solely to hash out what exactly those requirements are. Same with existing codebase if you want to add feature X and scope of that is well defined. But I suspect quite a few applications / projects / websites / tech startups / software libraries have started life with a "hey, that's neat. Let's take X, glue onto Y, tinker & play with it, see what we can do with that". Small / cheap 1st iterations don't involve much wasted effort anyway. Worst case = 0 useful code but you have learned something. When utility has shown & you get a sense of where you want it to go, then bring in the design aids for a proper v1.x, 2.x etc.
  - ryanklee 3y ago
    Better ways to go about it than impertinent and presumptuous interrogation.
EvanAnderson 3y ago
> What's your installer story? For installable software, do you know how to produce the installer for it? Too often the installer work is left until just before launch Putting on my sysadmin hat: Please do this. Please. Think about the people who have to install and maintain your software. Talk with real sysadmins about how they deploy software if you don't have experience doing it. Think about how you'd deploy, remove, and update it on large numbers of machines-- particularly where the users don't have administrative rights or where the machines are automatically-provisioned "cattle". Also, use off-the-shelf installer systems, if you can, versus rolling your own. The maintainability will be a lot better.
- gmane 3y ago
  I thought my software should randomize config and install locations for security reasons? And also that I should add salt to binaries so that each binary has a unique hash. Also it should prompt users to change passwords every 72 hours and lock them out after two incorrect tries. Also, for database connections, it should require the connection to the database be on a non-default port. Also, it should not be possible to administer over SSH, only over telnet.
- ZeroClickOk 3y ago
  Or at least do as portable as possible. Just copy and paste a folder, and `dot net run` will be amazing....
sanitycheck 3y ago
Or, stealth mode: Check it into a repo, but a private one. Nobody else even knows you're building the thing until you can demonstrate utility. Avoids all the bullshit. Not saying it's better, but it can be the difference between achieving something and nothing.
- sowbug 3y ago
  It's a balance, for sure. It's great to get early feedback on both technical and product aspects of a project. But as you say, feedback can also kill the project if it's the straw that breaks the camel's back. Or it can be the support that keeps you going when you're thinking of giving up.

by sowbug 3y ago

scruple 3y ago

That all sounds wildly dysfunctional. I've worked in startups with single digit engineering teams, up to massive corporations with tens of thousands of employees. I have never faced this sort of bullshit. I'm not even sure how I would respond to someone asking me, "wait, you're building what? Where's your design? Who approved this? Why are you naming it this and not that? We already built this; why are you building a second one?" but I can be sure that whatever came out of my mouth would be step 0 of finding a new place to work.

valleyer 3y ago
Sure, some of that sounds like "red tape". But avoiding needlessly duplicated functionality seems like a rather noble goal to me, one that can save everyone a great deal of maintenance effort in the future.
- scruple 3y ago
  It's making blanket assumptions that a) the question asker knows better, and b) that no one bothered to think of any of this to begin with. That's not a functional way to approach organizational problems like teams building the wrong thing. Never mind that, I'd wager oftentimes the IC standing up a new repo isn't the right tree to bark up anyway. FWIW, I personally start new projects with a Software Design Intent document that explains what we're attempting to do and why with full disclaimers about what we do and don't currently know. Maybe I've just managed to hedge these people out.
  - sowbug 3y ago
    > Software Design Intent document That's great. But having written it doesn't mean that everyone has read it. And not everyone who has read it will agree with it. Or maybe the person who you thought would champion it has left the company. Or maybe the world has changed since you wrote it. You've probably heard the expression "no business plan survives first contact with customers." A corollary, in anything but an extremely top-down organization, is that version 1 of your planning doc is unlikely to perfectly describe the final product. > a) the question asker knows better, and b) that no one bothered to think of any of this to begin with Eh, that's assuming a fair amount of antagonism on both sides. Most people are reasonable and rational, and after the initial "WTF? Are you crazy?" handshaking, everyone can get on the same page. But that process takes time. If your first contact with a downstream person/team/group is right before your 1.0 is supposed to ship, then you're more likely to treat them as a roadblock. If you instead involve them early, get the WTF moments out of the way, and take the time to develop a relationship, then you've turned a potential roadblock into a stakeholder and advocate, and your SDI becomes a true representation of consensus, rather than a bludgeon.
    - scruple 3y ago
      > That's great. But having written it doesn't mean that everyone has read it. It's just describing the intention of the team at the onset. Nothing more. I will not update this document once things get really rolling, that's why we have design documents elsewhere. What I personally do with this thing is I put a checklist of "approvers" at the bottom and I send an e-mail to them all asking them to review it and give their nod of approval or otherwise. FWIW I'm in agreement with everything else you're saying here, though.
  - RetroTechie 3y ago
    > Software Design Intent document Sounds like a good way to nip the creative aspect in the bud. Sure, if a client comes to a software vendor with a clear plan, draw up good specs, requirements etc. before doing any design (or coding). Or code a quick 'n dirty proof of concept solely to hash out what exactly those requirements are. Same with existing codebase if you want to add feature X and scope of that is well defined. But I suspect quite a few applications / projects / websites / tech startups / software libraries have started life with a "hey, that's neat. Let's take X, glue onto Y, tinker & play with it, see what we can do with that". Small / cheap 1st iterations don't involve much wasted effort anyway. Worst case = 0 useful code but you have learned something. When utility has shown & you get a sense of where you want it to go, then bring in the design aids for a proper v1.x, 2.x etc.
- ryanklee 3y ago
  Better ways to go about it than impertinent and presumptuous interrogation.

EvanAnderson 3y ago

> What's your installer story? For installable software, do you know how to produce the installer for it? Too often the installer work is left until just before launch Putting on my sysadmin hat: Please do this. Please. Think about the people who have to install and maintain your software. Talk with real sysadmins about how they deploy software if you don't have experience doing it. Think about how you'd deploy, remove, and update it on large numbers of machines-- particularly where the users don't have administrative rights or where the machines are automatically-provisioned "cattle". Also, use off-the-shelf installer systems, if you can, versus rolling your own. The maintainability will be a lot better.

gmane 3y ago
I thought my software should randomize config and install locations for security reasons? And also that I should add salt to binaries so that each binary has a unique hash. Also it should prompt users to change passwords every 72 hours and lock them out after two incorrect tries. Also, for database connections, it should require the connection to the database be on a non-default port. Also, it should not be possible to administer over SSH, only over telnet.
ZeroClickOk 3y ago
Or at least do as portable as possible. Just copy and paste a folder, and `dot net run` will be amazing....

sanitycheck 3y ago

Or, stealth mode: Check it into a repo, but a private one. Nobody else even knows you're building the thing until you can demonstrate utility. Avoids all the bullshit. Not saying it's better, but it can be the difference between achieving something and nothing.

sowbug 3y ago
It's a balance, for sure. It's great to get early feedback on both technical and product aspects of a project. But as you say, feedback can also kill the project if it's the straw that breaks the camel's back. Or it can be the support that keeps you going when you're thinking of giving up.