Marxist Hacker 42's Journal: WALDO- a way to merge software methodologies

I've been thinking a lot about the software methodology religious wars lately. It seems to me that all methodologies have their strength and weaknesses. 15 years in, Agile has given us faster coding, but worse quality. Waterfall was flawed due to its overemphasis on architecture and underemphesis on business. Lean cuts out inefficiency- at the cost of elegance and maintainability. Devops sacrifices quality and cheapness for speed of continuous Outcomes. And while it's true that the "User Interface is everything" because that's the only thing the user sees, Outcomes sacrifices the future for one-off unmaintainable code.

So here's my solution- WALDO. The ultimate 3-6 person team- no more than 6, no less than three if a couple of guys wear multiple hats.

W- Waterfall

A- Agile

L- Lean

D- Devops

O- Outcomes

But these aren't just methodologies- they imply roles on the team. The ideal six person team consists of:

W- The customer's view of the project should always be waterfall with iterations. They tell us what they think they want, we build it- they're involved in every iteration. Of course, they don't really know what they want- it takes several iterations before we discover what they want- but the W role is the customer herself.

WA- The Waterfall Architect, or perhaps the Waterfall Analyst. This is the guy who is the face of the team to the customer- the single point of contact. On smaller teams, may also be the scrum master- but ideally should be a master of the models. This person should also be the principle advocate in scrum meetings for the customer.

AL- the real scrum master should be a master of both Agile and Lean. This guy lives in the world of Gantt charts and excel spreadsheets- keeping both schedule and budget, keeping the team on schedule, communicating that schedule to the team and to the WA and W. Daily scrums should keep people on task.

LD- the Lean Developer is a Model First Full Stack Programmer, but is the king of Object Orientation, maintainability, and reuse. It is this role that you want somebody who excels in data- but can work in the higher tiers of programming right up to the User Interface Tier.

DO- the ultimate Devops guy should be as much artist as programmer- a whiz of the User Interface. This is what the customer will see, so the DO and the WA are a natural Quality Assurance feedback loop for each other. Since the DO consumes data and objects coded by the LD, there's a natural QA feedback loop there as well.

O- the Outcomes guy. QA and Build Engineer rolled into one- this is your build manager, working with WA and W to make sure every release happens quickly and accurately, and that beta testing actually occurs to provide data back to WA.

This is my ideal team- one that insures you get the best of all methodologies, not the short sightedness of focusing on one or two.

Re:

[Marxist Hacker 42]

with too many parentheses.

WALDO

[smittyoneeach]

Why
All
Legitimate
Data modelers H8
ORMs?

Re:

[Bill Dog]

Because they believe that it is the data storage that should be modeled, instead of the interaction of domain objects?

Re:

[smittyoneeach]

That is an excellent answer.

Re:

[Bill Dog]

For simple CRUD applications, where there really is no interesting application logic to model, then that makes sense. This is what most of the apps are where I currently work. Just data input forms, essentially, and reports.

Then we had to make a kind of personnel scheduling app. I.e. non-trivial application logic, with all kinds of special conditions and rules. It's a house of cards, because it wasn't designed. It was just hacked, because of thinking like yours.

Re:

[smittyoneeach]

How is life itself not just a series of hacks? one wonders.

Re:

[smittyoneeach]

The analogy I use, and you're free to hate it, is that of a large department store. The database is like the back storeroom, the staff is the logic, and the interface is the showroom floor. How you manage the state of a kid's bike is different from when it's in the box in the back, vs. how you set it up, vs. how you retail it to a customer.
An ORM is very focused on how the staff is shuffling one specific bike around. It's important, but not the full question.
Theologically speaking, programming seems to be

Re: WALDO

[Bill Dog]

It looks like you meant to reply to someone else, who was evidently arguing that you only need to model the business logic. Which of course is only true when the data storage is trivial.

I know MS's ORM for .NET, Entity Framework, for example, supports calling MS SQL Server stored procedures. The DBA staff can and ought to be able organize the data however over-normalized their little naive hearts desire, as long as they map it to the interface for the next layer. (Just as in ASP.NET MVC the proper (not t

Re:

[smittyoneeach]

It's all fun and games until your script kiddies start using migrations, no?

Re: WALDO

[Bill Dog]

I dunno, I've never used it/been at a job that has (yet, hopefully), I've only taken a class on an early version of it, 2009 or 10ish. Which I believe was before what I'm guessing you revile â" "code first" â" and other such evil features, and, probably not coincidence, before it was considered a proper OR/M.

p.s. I just thought of a new term to hereby officially invent: data kiddie
It's someone who's just barely out of their 20's who is a (good) sysadmin and thought, gee, how hard could (adding to

Re:

[smittyoneeach]

Everything is easy. In a development environment. With fake data.

Re: WALDO

[Bill Dog]

Maybe using an OR/M *efficiently* isn't.

Don't hate powerful tools, just learn how to use them properly. Hate the people too lazy to. Even if a majority of users of X use it terribly, it doesn't make X terrible. If I thought that way, I'd be for banning automobiles. Not to mention, that's how we ended up with Java.

Re:

[smittyoneeach]

I'm goofing off a little bit with SQLAlchemy in my spare time. I want to see if I can have it both ways by using the ORM as a design tool to generate SQL at design time only, and not have to pay for it at run time.

Re:

[Bill Dog]

I like this from the wikipedia page for it:

"SQLAlchemy's philosophy is that SQL databases behave less and less like object collections the more size and performance start to matter, while object collections behave less and less like tables and rows the more abstraction starts to matter."

Tomorrow I'm going to look more into the Active Record pattern vs. the Data Mapper pattern. (And I've no idea which (if only one) EF conforms to.)

Re:

[smittyoneeach]

I'd speculate the former. But the wikipedia remark (I saw that on SQLAlchemy.org) gets at the general lack of one-size-fits-all answers in The Biz. Which is why I tend to discount anyone spouting off with one-size-fits-all answers for any technical concept.
That said, any specific technical problem does have a context, and one should be competent to get close to a decent answer, if only by elimination.

Re:

[Bill Dog]

The problem with EA concepts is that they're presented via EA terminology. And vice-versa. I don't know if I'll ever get there in my career.

And I get the impression that some EA patterns aren't mutex, but at different levels. Making if confusing to try to Goog what EF implements vice what it allows one to implement.

But my understanding is that Active Record is (usually not recommend and) requires your business objects derive from some base class provided by the OR/M. Which I don't think is required in EF (a

Re:

[smittyoneeach]

The point is one of scale. Active Record means that you're constructing a class for every row of data you touch. In a dynamic language. When all that scripty dynamism is going completely unused.
There is a special kind of illness one feels from seeing associative arrays browbeaten into doing a "find unmatched" query.
But I think the real evil of the Active Record pattern, and the Migrations that come with it, is that it leads to a total lack of discipline when the little browser whiz kids figure that making

Re:

[Marxist Hacker 42]

That would be the guys at ClearThinking Software in England, who think a relational database doesn't need any relationships, foreign keys, or primary keys. 200 tables, not a single relationship.

moof

[Bill Dog]

15 years in, Agile has given us faster coding, but worse quality.

You mean worse quality than Waterfall when you don't count Waterfall's higher failure rate [infoq.com]? Because I think I would factor those in as zeros in the quality dept.

Waterfall was flawed due to its overemphasis on architecture and underemphesis on business

We do Waterfall where I work, and I assure there's no architecture going on! To me Waterfall is an overemphasis on taking the customer's word for it on what he wants and an underemphesis on the re

Re:

[Marxist Hacker 42]

"(on Time, On Budget, on Target, on Goal, Value and Satisfaction)"

I suggest that these are not exactly the best criteria for determining success or failure. With these criteria, a one off VBA script in a spreadsheet is as successful as a word processor that has survived in the marketplace for 25 years.

Waterfall should assume that any given product is going to stick around for longer than a season- and that's why waterfall done right imitates Agile by building a prototype and going through a couple of itera

Re:

[Bill Dog]

The problem with prototypes is that your bosses then order you to just add on to them to build the real system.

And big, up-front specification as a process can't keep up. Agile is a facing of reality, as ugly as it is, that waterfall denies.

Re:

[Marxist Hacker 42]

And yet, the customers still think in waterfall- thus the need for the WA role above, somebody who understands both Waterfall and Agile and can push waterfall requirements into Agile iterations.

Re: moof

[Bill Dog]

They think in Waterfall, but act in Agile*. Hence you're dead right on the "thus".

*They want a contract defining the terms so the software builders can't change, after it's been agreed upon, what is to be built. But they want to be able to do so. To me Agile is the realization that all orders for custom software are one-way contracts.

Re:

[Marxist Hacker 42]

So a corrolary to WALDO is- never write a contract for a defined money amount. ALL contracts should be time and materials for any custom software.

Note the W position in the team above- is reserved for the customer- the guy we're trying to teach the rest of this stuff to.