hellsten + software-development   13

Don't measure developers, measure projects | Hacker News
- Don't automate what you can't first do manually. Your best developers might be helping, supporting, designing and architecting your next solution.

- One commit, one PR, might prove more valuable for your business than hundreds of other tickets closed.

- Remove the KPIs and talk to your team members in 1-on-1s regularly. Give responsibility and trust to your team, and they'll be self-empowering.

- Add KPIs and you'll take away their responsibility. Trust will be lost. Probability for innovat...
business  architecture  project-management  software-development  management  leadership 
15 days ago by hellsten
The State of Agile Software in 2018
- The point is, the team doing work decides how to do it. That is a fundamental agile principle. That even means if the team doesn't want to work in an agile way, then agile probably isn't appropriate in that context, and [not using agile] is the most agile way they can do things in some kind of strangely twisted world of logic.

- When I summarize agile to people, I usually say there's two main pieces to it. One, I've already talked about, the primacy of the team, and the team's choices of how they do things, but the other is our ability to change rapidly, to be able to deal with change easily.

- The third thing that I want to stress is the importance of getting rid of software projects as a notion. Instead we want to switch to a product-oriented view of the world where instead of projects that you spin up, run for a while and then stop; you instead say, "Let's focus on things that are much more long-lasting and organize a product team around that." Another way of thinking about it is: what are the business capabilities that your organization has, and then organize the teams around those.

- When [at Snowbird] we were talking about names for agile software development, Kent Beck suggested "conversational", because there should be an ongoing conversation between software developers, business people, and anybody involved in making that customer experience better.

- I think Ron Jeffries joked that Allistair Cockburn's approach to agile was "come together in peace and harmony, deliver software every week, and do a retro every time to figure out how you can improve".

In particular, one of the really central things that impressed me very much about the early agile advocates was this realization that people are operating at the best when they choose how they want to work.

When we talked about the Agile Manifesto and laid out the four value statements, with most of those value statements, we didn't care very much about what order they came in. But we did have an opinion about the first one: which is "Individuals and Interactions over Processes and Tools". To me that crystallized a very important part of what agile thinking is about. If you want to succeed in doing software development, you need to find good people. You need to find good people that work together at a human level, so they can collaborate effectively. The choice of what tools they use or what process they should follow is second order. I thought that's a very important statement to come from what was basically a gathering of process weenies. I mean we were all process guys to some extent or other, and yet we were acknowledging that what we were talking about was actually of secondary importance. What matters is that the team chooses its own path.

It goes further than that for the team should not just choose the process that they follow, but they should be actively encouraged to continue to evolve it and change it as they go. One of the things about any kind of agile processes or agile method is that it is inherently very slippery. It changes week to week, month to month. One of the quotes that I used to flash around people was "if you're doing Extreme Programming the same way as you were doing it a year ago, you're no longer doing Extreme Programming".

- retrospectives are clearly a technique that lots of people find to be really very central.

- This is a reaction against the whole Frederick Taylor, separate process people.

He's probably one of the most important figures in the history of the 20th century in terms of how he's actually affected people's day to day lives. He was from the late 19th century, in America, and he was very interested in trying to make people more efficient in the industrial workplaces that were developing at that time. His view of the average worker was that they were lazy, venal, and stupid. Therefore you didn't want them to decide how they should make a particular piece of machinery, but somebody else, somebody who was a more intelligent and educated, they should figure out exactly the best way to do it. Even going down to: do I do this and then that or do I do that and then this. This is a very scripted sense of motion and movement. The whole time and motion industry came out of that. At the heart of this notion was that the people who are doing the work should not decide how to do it. It should be a separate group of planners who does this, and that strongly affected manufacturing and factory work through much of the early 20th century.

And it affected the software industry as well - people said, "we need software process experts to figure out how to do things, and then programmers just fit into the slots".

- The agile movement was part of trying to push that, to try to say, "The teams involved in doing the work should decide how it gets done," because let's face it, we're talking about software developers here. People who are well paid, well educated, hopefully, well-motivated people, and so they should figure out what in their particular case is necessary.

- And yet what I'm hearing so much is the Agile Industrial Complex imposing methods upon people, and that to me is an absolute travesty.

- "I'm refactoring our software at the moment, so it's going to be broken for the next two weeks." Bzzz - that's not refactoring. Refactoring is small changes, each of which keeps everything working. It doesn't change the observable behavior of the software, that's its definition. And I should know because I was the one who got to define it.

Refactoring is lots of small changes, none of which change the observable part of the software, but all of which change its internal structure.

- So my three things, that we should face as challenges:

1. Get rid of the Agile Industrial Complex and the idea of imposing stuff on teams. Let teams work out the way they should work themselves.
2. Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and
3. organize around products.
agile  scrum  extreme-programming  software-development  details  business  project-management  product-developmentment 
6 weeks ago by hellsten
Auto DevOps | GitLab
Auto DevOps brings these best practices to your project in a simple and automatic way:

Auto Build
Auto Test
Auto Code Quality
Auto SAST (Static Application Security Testing)
Auto Dependency Scanning
Auto License Management
Auto Container Scanning
Auto Review Apps
Auto DAST (Dynamic Application Security Testing)
Auto Deploy
Auto Browser Performance Testing
Auto Monitoring
devops  architecture  software-development  best  details 
9 weeks ago by hellsten
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.

Example:

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:



description:


tags: