Popular posts

If I'm following your question correctly, I believe the term you're looking for is architecture. Specifically "Software Architecture" and "Database Architecture", methodologies that separate "slapping code together any old way" from working as a professional that treats programming as engineering.

And why this new "software engineering" catchphrase IMHO has little to do with actual engineering since they lump -- what are in my opinion and experience -- bad practices like Agile under that banner. Agile -- aka "making it up as you go along" -- is everything BUT engineering.

Though nowadays a lot of stuff that was simple architecture gets slopped under the Software Engineering catchphrase. Shame as the concept of applying actual engineering to software is a sound one, but so much of what's being lumped into it has nothing to do with that.

The engineering and architectural aspects you seem to be asking about is best thought of as dependencies. The order in which to implement things being dictated by the order in which they depend on each-other; and that whenever possible the data structures should be defined and established FIRST.

This is much akin to how on the front-end we have the concept of progressive enhancement, where you layer the fancier technologies atop a sound baseline. You start with the most important thing -- the content -- and arrange it to make sense in a flat text editor as if HTML doesn't even exist. You then add the semantic HTML to say what things are and not what you want them to look like, then bend it to your will with CSS to create the layouts.

Said approach creates a dependency chain, where the content dictates the markup, the content + markup + device capabilities dictates the style, and all of that should once fully working dictate any enhancements done with JavaScript... and is why if you start out with style, or scripting, before you have that semantic baseline the site is almost always a broken bloated inaccessible nightmare on both the UX and sustainability front.

Your database structures and logic flow should be similarly organized. Start with the content first. What is the data. How are you going to organize the data? What data relies on other data to function properly. Similar to the waterfall approach except instead of a straight line you have a tree.

You mentioned "roles, groups, users" -- by roles do you mean user-level permissions as opposed to group-level? If so that's the "wrong order". How can you have groups or permissions without users to assign to it? Take a forums or a blog where people can reply to posts. The only time you're pulling permission data is when they are posting, so you don't want to keep that in the same table as the user, you want to make another table for grabbing their permissions as needed. Permissions may be set by groups or individually so you would make users first, and then tie the latter two to the user id first.

Working with data structures first also means you have everything in place to add data letting you properly develop the front end. I've seen so many projects bend themselves over the table by screwing around trying to make a front end before data structures are even established -- end result being the back-end guys having to try and shoe-horn the actual data into layouts that weren't designed for it!

Part of why I'm so vehemently against the "PSD first" approach to development. Photoshop jockeys and other such artists should be brought in last to paint-by-numbers, not be your go-to guys for design! They are not web designers, they're artists under a delusion of grandeur.

If you have the data structures determined -- as much as possible -- first, you can build your logic to process it. You can build your front-end based on the data and the output of the logic. It gives you the architectural foundation instead of running at things blind and willy-nilly.

Later implementation of features -- which is a reality we all must face -- should still follow the same approach. Make the data structures based on dependency, make the logic, then pretty up the output from that logic.

To me, that's the architectural approach. Some other techniques are called "software architecture" (or nowadays engineering) that to me fail to live up to the term, since other approaches do not seem to care about dependencies, much less building a firm foundation and progressively enhancement.

... or worse, get crammed into places where the patterns make little to no sense, such as MVC when working with request based PHP. What PHP "MVC" systems call the model, in any other software model large sections of which would still be the view. It doesn't fit the underlying architecture of the language, where requests are coming from, and where the results are going! I applaud the separation of concerns, but that "paradigm" just draws the gridlines in the wrong places.

... and be prepared for a LOT of sick buzzwords if you start researching Software Architecture/Engineering. If you've learned about the propaganda techniques work and how legalese / market-speak / glittering generalities are leveraged to make things sound more important than they are, you'll find yourself knee deep in proactive paradigms of out of the box innovation-jacking netiquette, where realtime engagement -- without triggering pain points of wantrapreneurs -- leverages the illusion of transparency whilst retaining an avant-garde approach to a best in breed win/win value proposition...

For those of you who missed it, that's called a sense of humor. You should try it, it's nice.

For those of you who missed it, that last "for those of you" is a quote, and a funny one.

Jason, what does Mr. J keep telling you? If you have to explain the joke it isn't funny.

Sorry but "interactive properties" is exactly what I mean by "Glittering generalities". It means nothing to me as a developer who's been at it twice as long as you. Just seeing it made me laugh, because I've seen it thrown around without meaning in things like those silly "stand up" meetings that are all hot and trendy right now; where lots of things are said but nothing is accomplished.