Hacker News Reader

Comment by sowbug | Hacker News Reader

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.

View on HN

> 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.

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.

Or at least do as portable as possible. Just copy and paste a folder, and `dot net run` will be amazing....

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.

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.

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.

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.

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.

> 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.

> 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.

> 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.

>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

The odds you're the first one to have thought of something are [practically] zero

The odds you're the first to implement something are only slightly higher

When you find out someone else has already built 89% of what you're looking for (and 213% of what you hadn't thought of yet, because they already ran into the corner cases and what-ifs you couldn't possibly have thought of until you hit them), you can save yourself (and the organization) loads of effort by extending what's there instead of building from scratch

Maybe you're the first to think of it and first to build it

But you're probably not - and getting that early feedback from someone who sees what you're working, and says, "why are you building what Sally & Tom built last spring?" is absolutely invaluable

Better ways to go about it than impertinent and presumptuous interrogation.

Reply on news.ycombinator.com