81–90 of 201 posts
It does not work when it’s used as a magic machine of happy fun time productivity…. Sprints and stories don’t translate into more productivity. Focus and teamwork do.
Earlier quoted context omitted.
The 1968 NATO SE conference is also the earliest reference I know of discussing software reuse (page 79 of the PDF, "Mass Produced Software Components"). Interesting to see how some of the problems then are still problems today.
Some?
They work, but you still need very capable people (developers, managers, product owners, etc). Furthermore, if you have a very capable team, you may not even need a formal "Methodology".
Once you break a project down into subcomponents that interact, you need to coordinate release of any changes to interfaces, so the work of one team doesn't break the work of another.
This made me think about the book "Shop class as soul craft". Cars use to be made by hand by skilled artisans. So did software. As with any process of production the move to change it in to a documented repeatable process complete with middle management has taken place.
A better analogy might be: how do you go from a blank whiteboard to Ford Fusion Hybrid #1?
Earlier quoted context omitted.
I left my last job because my time had degenerated from doing cool stuff to fixing the stupid errors that my colleagues were making because they were lazy. Allowing some coders to be lazy in terms of adherence to coding standards and methodology has to be one of the best ways to get rid of your good programmers. For example, we had coding standards requiring a comment explaining the contract for each method written,…
That sort of thing has an obvious problem. Take a fairly simple class: class Shape { public: void SetAbsolutePosition(uint x, uint y, LengthUnit units = LengthUnit::PIXELS); void SetRelativePosition(int x, int y, LengthUnit units = LengthUnit::PIXELS); void SetXAbsolutePosition(uint x, LengthUnit units = LengthUnit::PIXELS); void SetYAbsolutePosition(uint y, LengthUnit units = LengthUnit::PIXELS); void SetXRelativePo…
But of course I meant my earlier comment particularly for quite complex methods that had very ambiguous behaviour unless defined in a comment that could act as a contract. The contract can then be enforced by writing tests against it, and you know your code works when the tests pass.
It's very common to write the code first, write the tests against the code, and then write a comment against the code if you are lucky, but that doesn't actually prove anything, as the tests will be testing the implementation details, not the contract.
In my experience, these methodologies are best described as cultish. The form of religion but not the power. Here's my methodology. * Figure out what the software does, what the business cares about, and what the users care about. * Figure out what it kinda sorta needs to be under the covers * Write prototypes of the technically gnarly bits. * Flesh out the prototype and start writing integration/functional tests for…
That's a great solution when you understand the problem. Process is great when nobody can understand the problem. Windows is a great example of this, nobody at Microsoft really understands even 1/2 of what Windows does internally down at the code level. Now, how do you ensure a useful update comes out the door in 2015? PS: Granted if you deal with less than 30 people process tends to be overrated.
So, let's assume that different approaches work for different numbers of people (shocking).
How would you break down work for a > 1 MLoC codebase with lots of people on it? How do you ensure it gets done?
I would do it by having 1 person operate as a system integrator with responsibility for designing interfaces at the top level, then farming out the subcomponents to each subteam, until this reached the point of implementation. Lots of these things can be specified up front (front end! back end! database! integration with other systems! tooling! algorithms! shared utilities!) . As development ensued and new knowledge found, responsibilities would shift and new teams formed/older teams reassigned. Several key thoughts here: 1 person owns the vision of the system (call them the systems engineer), interfaces define interactions with other parts of the system, teams responsible for tightly cohesive components with loose coupling to other teams. Mind you, that's sort of Fred Brooks-ish, but why not? We haven't gotten too far from Psychology of Computer Programming in actual practice.
It's fun to watch observations like the following re-discovered again and again. From the NATO Software Engineering Conference in 1968: Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. Fraser: One of the problems that is central to the software…
An important realization I made a while back was that design methodologies do little to address program correctness, which is almost always the wildcard on deliverables; buggy software means missed deadlines and budget. Some, such as TDD, work to address the rapid building of tools to a particular spec, but often fail to promote static guarantees, especially in languages and environments where such provability is lar…
I think that's one aspect of the problem, but the migration from make-do to mathematically rigorous code can be equally fraught with peril. While the code itself can be made predictable, and easy to reason around, the time estimates and project planning often cannot. There is never enough time to factor out all of the commonality, remove all of the unnecessary use of state, codify all the assumptions into data types,…
Part of the beauty of proof is that so long as it is correct, the individual lemmas are largely irrelevant: we don't necessarily need to remove commonality or statefulness. Of course, I'm purposefully glossing over extra-functional requirements on which, outside of big-O, we don't have a firm grasp.
I'm attempting to stay away from "effective" or "most work done" since they're ill defined and highly subjective but rather focus on measurable changes. I'd argue that, amortized, the upfront costs of better understanding the problem definition results in cost savings down the line, especially as it recedes into maintenance.
An important realization I made a while back was that design methodologies do little to address program correctness, which is almost always the wildcard on deliverables; buggy software means missed deadlines and budget. Some, such as TDD, work to address the rapid building of tools to a particular spec, but often fail to promote static guarantees, especially in languages and environments where such provability is lar…
" I find it no surprise that the larger companies have made foundational maths, such as category theory and abstract algebra, the underlying abstraction for their general frameworks. " I would like to learn more; do you have a specific example? Having worked with real "engineer" engineers, I've found that they have, and value, a considerable amount of mathematical education, but that education is all in continuous ma…
1. https://github.com/twitter/algebird 2. https://github.com/non/spire