hellsten + software-development   10

My 20-Year Experience of Software Development Methodologies | Hacker News
There is an insider story about how these methodologies comes about. So there are few groups of people whose sole job is to do consulting on failed/late/over budget projects. Mind you, they don't write code but rather they observe how things are going and then prescribe process/management improvements (McKinsey style). Once in a while, these folks bump in to terrible projects and whatever they prescribed sometime works like a charm. In that case, they take that prescription on road and advertise the hell out in conferences, magazines, blog posts. Unlike regular developers, they have all the time in the world to do these activities. They write books and give interviews and by the media power of distributing information suddenly they pop out as process gods who knows how to fix any project. Eventually the new things starts to fad, people realize what works in project X didn't worked in Y, speaker engagements starts drying out and then these folks need new thing to repeat the cycle.
The obvious problem is that these folks prescribing the development process are not active developers. They are not even part of any real project over any long duration. They are in job of inventing and selling processes and handing out management advice as consultants. Whatever they prescribe, might have worked only in specific context and for specific symptoms, usually with huge dose of luck. Next time when you see new process fad, look up the history of originator of this process, what company he is part of, how much code has he written, how he makes money. You will know what I'm talking about.
methodologies  process  idiots  software-development  hn 
october 2017 by hellsten
Streams: a new general purpose data structure in Redis | Hacker News
One thing I like about this post is the story of how the feature came to be: Someone who understood redis very well, thinking about the problem over literally years, eventually resulting in a more targetted and goal-driven thinking, and even that "specification remained just a specification for months, at the point that after some time I rewrote it almost from scratch in order to upgrade it with many hints that I accumulated talking with people about this upcoming addition to Redis."
I've been thinking about this sort of thing for a while, wanting to maybe call it "slow code" (like "slow food"). This is how actual quality software that will stand the test of time gets designed and made, _slowly_, _carefully_, _intentionally_, with thought and discussion and feedback and reconsideration. And always based on understanding the domain and the existing software you are building upon. Not jumping from problem to a PR to a merge. (And _usually_ by one person, sometimes a couple/several working together, _rarely_ by committee).
management  software-development  redis  hn  process  thinking 
october 2017 by hellsten
On the Unhappiness of Software Developers | Hacker News
1. Being stuck in problem solving
2. Time pressure
3. Bad code quality and coding practice
4. Under-performing colleague
5. Feel inadequate with work
6. Mundane or repetitive task
7. Unexplained broken code
8. Bad decision making
9. Imposed limitation on development
10. Personal issues – not work related
I've dealt with most of these, and I think they betray the mantra of the "modern" software engineer: push features fast. Code quality, adequate explanations, proper planning, and lenient time tables are an afterthought.
happiness  work  career  software-development 
june 2017 by hellsten
The most important skill in software development | John D. Cook
Here’s an insightful paragraph from James Hague’s blog post Organization skills beat algorithmic wizardry:

When it comes to writing code, the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity. I’ve worked on large telecommunications systems, console games, blogging software, a bunch of personal tools, and very rarely is there some tricky data structure or algorithm that casts a looming shadow over everything else. But there’s always lots of state to keep track of, rearranging of values, handling special cases, and carefully working out how all the pieces of a system interact. To a great extent the act of coding is one of organization. Refactoring. Simplifying. Figuring out how to remove extraneous manipulations here and there.

Algorithmic wizardry is easier to teach and easier to blog about than organizational skill, so we teach and blog about it instead. A one-hour class, or a blog post, can showcase a clever algorithm. But how do you present a clever bit of organization? If you jump to the solution, it’s unimpressive. “Here’s something simple I came up with. It may not look like much, but trust me, it was really hard to realize this was all I needed to do.” Or worse, “Here’s a moderately complicated pile of code, but you should have seen how much more complicated it was before. At least now someone stands a shot of understanding it.” Ho hum. I guess you had to be there.
software-development  engineering  algorithms  advice  best  programming 
june 2015 by hellsten
.net - How do you effectively model inheritance in a database? - Stack Overflow
Proper database design is nothing like proper object design.

If you are planning to use the database for anything other than simply serializing your objects (such as reports, querying, multi-application use, business intelligence, etc.) then I do not recommend any kind of a simple mapping from objects to tables.

Many people think of a row in a database table as an entity (I spent many years thinking in those terms), but a row is not an entity. It is a proposition. A database relation (i.e., table) represents some statement of fact about the world. The presence of the row indicates the fact is true (and conversely, it's absence indicates the fact is false).

With this understanding, you can see that a single type in an object-oriented program may be stored across a dozen different relations. And a variety of types (united by inheritance, association, aggregation, or completely unaffiliated) may be partially stored in a single relation.

It is best to ask yourself, what facts do you want to store, what questions are you going to want answers to, what reports do you want to generate.

Once the proper DB design is created, then it is a simple matter to create queries/views that allow you to serialize your objects to those relations.


In a hotel booking system, you may need to store the fact that Jane Doe has a reservation for a room at the Seaview Inn for April 10-12. Is that an attribute of the customer entity? Is it an attribute of the hotel entity? Is it a reservation entity with properties that include customer and hotel? It could be any or all of those things in an object oriented system. In a database, it is none of those things. It is simply a bare fact.

To see the difference, consider the following two queries. (1) How many hotel reservations does Jane Doe have for next year? (2) How many rooms are booked for April 10 at the Seaview Inn?

In an object-oriented system, query (1) is an attribute of the customer entity, and query (2) is an attribute of the hotel entity. Those are the objects that the would expose those properties in their APIs. (Though, obviously the internal mechanisms by which those values are obtained may involve references to other objects.)

In a relational database system, both queries would examine the reservation relation to get their numbers, and conceptually there is no need to bother with any other "entity".

Thus, it is by attempting to store facts about the world—rather than attempting to store entities with attributes—that a proper relational database is constructed. And once it is property designed, then useful queries that were undreamt of during the design phase can be easily constructed, since all the facts needed to fulfill those queries are in their proper places.
database-design  architecture  inheritance  software-development  details  best 
june 2015 by hellsten
The Architecture of Open Source Applications
Our goal is to change that. In these two books, the authors of four dozen open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to these books provide unique insights into how they think.
architecture  software  book  open-source  software-development 
july 2014 by hellsten
Ask HN: How do you know when to quit your startup? | Hacker News
It's funny that code rot is so inevitable. Some people think that the code just needs to be written and designed very well to avoid technical debt. But it always rots in some way. Even if the code is never changed or amended and no new complexity added, it rots because api's, platforms and basically the tech that surrounds and it relies on changes.
technical-debt  software  software-development 
july 2014 by hellsten
Facebook forces all users over to Facebook.com e-mail addresses | Hacker News
Zawinski's law of software envelopment:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
software  funny  zawinski  facebook  myspace  software-development  bloat  features 
june 2012 by hellsten
Brad Fitzpatrick (of LiveJournal, now at Google) Talks About Programming
In practice, nothing works. There are all these beautiful abstractions that are backed by shit.

Always try to do something a little harder, that’s outside your reach. Read code. I heard this a lot, but it didn’t really sink in until later.
programming  development  philosophy  software-development  details 
november 2009 by hellsten

Copy this bookmark: