> I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an admin change guidance on the fly, without touching HTML. Fields could be re-sequenced, data types changed. Business rules could be linked to fields dynamically, and applied to single fields or entire form sections. Data was saved to a SQL Server (already in wide use in the estate). My proof of concept took 4 weeks, and on the basis of that I estimated a 6 month project. When I presented the idea it was viewed as being too complex, and therefore too risky.
Was your flexibility in the right direction? I could tell you exactly the opposite horror story, where an enterprise architect built in a bunch of flexibility that we never used, but we still spent a load of time changing everything as the customer requirements changed. Only we had to spend twice as long because we had to change everything in three places because the "flexible design" required that.
> Of course soon after the customer decided that the guidance for the printed form wasn't appropriate for the online version. And of course the customer wanted to analyse data across all forms. What was a 6 month piece of work took 3 years. And still no ability to analyse data nested in Mongo documents. Any change requires hours of re-work, regression tests and sign-off.
Why would your way have been different? If you are using the database to store logic in, it's still logic and still needs the same level of testing as it does in code. And you don't get existing tools like VCS, release systems, staging environments to help you with that.
I know we're just comparing anecdotes, but everywhere I've worked the business effectiveness has been directly proportional to the extent to which they actually followed the agile principles.
You know, a lot of failed projects that I've worked on were my fault, because I was that guy. The guy who questioned the seasoned greybeard. The guy that knew JavaScript is the only answer. That agile is the only way to manage development. And if agile didn't work, it wasn't because agile was a bad choice, but because you were doing it wrong. That document databases can replace relational databases. That dependency injection is good. You get the idea.
What sounds good, looks good and feels good is sometimes, and sometimes very often, very bad.
The thing someone in their 20's doesn't know is that people in their 20's don't know. People in their 30's that are even vaguely in touch with themselves start realising they don't know. In my late 30's I questioned whether I'd wasted my entire career by not learning anything. Today I just know. I know an idiot before he opens his mouth. And I see a bad design decision happening when the team is assembled, before anyone has even started to design anything. That the 5th sentence in the 5th paragraph of this post is badly structured. Most importantly, today I know when I don't know.
I still fuck up. Spectacularly so, sometimes. But not as often as 30 years ago. And not as often as last year. Or last month. I happen to have been right in my post above. Hindsight proved that.
I have a text editor that creates forms. I have a good abstraction for what a form is, meaning I can represent one with a simple class that expresses only the things that make that particular form unique. And I have a whole bunch of standard tooling around managing this representation of forms, like my VCS.
It sounds like you haven't really lost your certainty. "I just know. I know an idiot before he opens his mouth." - no, you don't, you can't. Being older doesn't prove anything - some of the worst decisions I've had to work with were made by the most senior people, and vice versa.
Indeed it doesn't. I know because I pay attention.
I'll put it another way - you can be young and not know. You can also be old and not know. However, you cannot be young and know. But you can be old and know. Old is usually, but not always, measured by time.
First, I sympathize with your reaction against building in functionality that is not required. This typically causes a lot of problems. However, for a library, that is less of an issue because you aren't maintaining it. It sounds to me like the guy used what was essentially a library he had previously developed to do this and that's a step towards having the flexibility in the right place.
> Why would your way have been different? If you are using the database to store logic in, it's still logic and still needs the same level of testing as it does in code. And you don't get existing tools like VCS, release systems, staging environments to help you with that.
My largest open source project does a lot with database stored procedures. We use all the tools you mention above, and we have written some of our own tooling to make that easier. So I don't think there is any reason why those tools don't work. So you have to spend a little time on tooling? That gets paid off many times over.
> I know we're just comparing anecdotes, but everywhere I've worked the business effectiveness has been directly proportional to the extent to which they actually followed the agile principles.
There are many things that agile gets right. As a reaction against the waterfall engineering model, the emphasis on integrating design into coding is a welcome advancement. There are many other things as well.
But agile development, because of short release cycles, tends to de-emphasize design and code contracts because it comes from the assumption of changing requirements, and here it gets a lot of things wrong. You can't do agile development if you don't have a stable platform to develop on because otherwise the ground is always being pulled out from under your feet. That platform needs to be well designed, and I am not sure you can do that iteratively without a fair bit of up-front thought. This doesn't mean a waterfall (except in the area of UX). Rather it means getting the right amount of design done at each level and having the right person do it.
> My largest open source project does a lot with database stored procedures. We use all the tools you mention above, and we have written some of our own tooling to make that easier. So I don't think there is any reason why those tools don't work. So you have to spend a little time on tooling? That gets paid off many times over.
Programming logic in the database, or config files, is a huge antipattern I've seen many times. People seem to have this huge blind spot where you can take the exact same piece of logic and label it "code" or "not code" and in one case it will be subject to review and signoff and all that and in the other it won't be.
You can always write your own programming language and tools, but you're unlikely to do better than the existing ones. So why not just use one of them?
Was your flexibility in the right direction? I could tell you exactly the opposite horror story, where an enterprise architect built in a bunch of flexibility that we never used, but we still spent a load of time changing everything as the customer requirements changed. Only we had to spend twice as long because we had to change everything in three places because the "flexible design" required that.
> Of course soon after the customer decided that the guidance for the printed form wasn't appropriate for the online version. And of course the customer wanted to analyse data across all forms. What was a 6 month piece of work took 3 years. And still no ability to analyse data nested in Mongo documents. Any change requires hours of re-work, regression tests and sign-off.
Why would your way have been different? If you are using the database to store logic in, it's still logic and still needs the same level of testing as it does in code. And you don't get existing tools like VCS, release systems, staging environments to help you with that.
I know we're just comparing anecdotes, but everywhere I've worked the business effectiveness has been directly proportional to the extent to which they actually followed the agile principles.