Hacker News Reader

Comment by DogLover_ | Hacker News Reader

Someone suggested this on my team. I personally don’t like the idea because these policies often times lead to bureaucracy and then nothing getting released. It is not that I am against thinking ahead but if i have to in details explain everything I do, then more time is spent documenting than actually creating which is the part I enjoy.

View on HN

I get it, that's indeed the fun part.

But, do you believe the statistic that 90% of the cost of software is the maintenance?

If so, then the only way you can be a mythical 10x engineer is if you are willing to do things that really reduce the team costs. Everything else about 10x engineers is just mythology.

I think this is an example / practice of one of those things you can do for your team. Communicating clearly up front, being willing to discuss and alter poor thinking (everyone does it) is what turns individual contributors into powerful team members. If you just start with coding, you are missing all that part of it.

Documenting/communicating what you do is important but when it becomes a process it can really be detrimental. Every new feature won’t take the same amount of time and having to spent time writing down my approach for a task that will only take a few days will likely just limit me. That time could be spent on writing (more) tests which is also a form of documentation. If we say that 9/10 times a solution is good, the time saved not writing down the approach could accumulate to 1 rewrite. Basically for me it boils down to some of the agile values and principless:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Working software is the primary measure of progress.

- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

https://agilemanifesto.org/principles.html

> do you believe the statistic that 90% of the cost of software is the maintenance?

Hmmm. Apart from the very suspicious number (90%) I wonder what exactly it's meant by "maintenance". Because it could be bug fixing, adding or changing features, refactoring, server or db administration, etc. And what period of time is included in the "maintenance" phase: one year, ten, a century?

It really depends on the team. There are many cases in my memory where it made sense to code out the skeleton of the plan, especially at integration points and module interfaces, so that it's explicitly clear to other developers what you plan to do.

White-boarding doesn't really address the problem because some of the thorny issues really are substantive scalability or maintainability considerations. I've found it much easier to discuss with mocked code.

Agree, it depends on company and team :)

We tend to split workloads among teams based on timezones, so using placeholder PRs are required if you're handing your ticket over to another timezone for the night.

If your workplace is optimizing for your enjoyment, there is probably a serious problem afoot. The value of thinking ahead, to be clear, is that it enables you to "actually create" something that isn't ill thought out, or worse, of no actual use to any person. It also allows your work to be understood by other people, who might have to duplicate it, review it, or extend it in the future. It is indeed unfortunate that all of these legitimate demands should intrude on your time that could instead be spent spewing out code.

Have to disagree. Many places try to optimize for enjoyment so they can keep their employees.

There is a time and place for everything. If you a working on a project that takes months it should be planned ahead but if it only takes a few days you might not need. Let us not forget why we got rid of waterfall model.

> Let us not forget why we got rid of waterfall model.

It's actually doubtful it ever existed: its first formal description, in the 1970s, is used as an example of a model that doesn't work.

Let me formulate the Godwin-Udik's law:

"As an online discussion on development practices grows longer, the probability of a mention of waterfall as a negative example approaches 1"

Interesting! Too young to have experienced waterfall model in a workplace. Are you saying it did not exists. If so what was the agile manifest a response to?

> what was the agile manifest a response to?

Frankly I don't know. The Manifesto itself is not very clear about it. I've worked in agile and non-agile companies, but none used a waterfall model. If anything, agile adoption always meant more process (stories, standups, planning, retrospectives, etc.) rather than less. Before or without agile, the structuring of work has been mostly the same, albeit without the formal process defined by this or that agile methodology (to be fair, scrum is the only one I've ever seen).

It was actually mandated for many government projects for a while. A good history of iterative development can be read here: http://www.craiglarman.com/wiki/downloads/misc/history-of-it...

> It was actually mandated for many government projects for a while

I have no clue about this, but I suspect that the government, rather than mandating a software development methodology, simply used to agree beforehand on what was to be delivered and expected to have it delivered at the end of the process. It's a constraint on how you sign contracts with external suppliers, not on how you write code- though I understand that the first influences the second.

In many industries as well as many government branches it still works just like that. They do not mandate a way of "writing the code", but software projects must pass gates and receive approvals at each stage before getting funding. They have to provide comprehensive analysis and architecture documentation that cover everything under the sun before a single line of code is written. And then, once a dev team starts coding, it has to go through the whole loop and if something specified doesn't make sense "on the real world". Or, more often, they just do the proper thing without telling anyone.

Writing down what you intend to do and verifying with your team it is sensible is not "the waterfall model". This "I just want to code" attitude is a major disease of young programmers and a leading cause of shitty software. Think ahead. Write it down. You are not a lonesome dove.

Thats a fair point, but I did not say that there should be no communication about the work you do. We all work differently and I think it is sensible to let each employee have some form of independence of how they want to structure their own work. If the feature is a few days of work let me work on it like I prefer and then I can submit with a nice description and thought process.

Let us also not forget about all the time wasted on getting your plan validated. Or how your validated plan is completely screwed only realized after you start implementing it. Pros and cons to each solution.

Again, there is no justification for just jumping in and writing code. Would you cut wood without measuring it first? Would you start soldering without laying out a circuit? Would you write an essay without an outline? You could do all of these things, but the results are guaranteed to be crap.

Reply on news.ycombinator.com