hellsten + software-development + details   5

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 
18 days 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 
5 weeks ago 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
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: