Timely—I had a conversation about this with a friend a day or two ago. There is a definite trade-off between novelty and productivity. IMO putting as much novelty into the parts of your domain logic that differentiate you from competitors as possible is the best trade-off. You want your complexity and learning curve tied up in the “magic” parts of your software, not the mundane pieces.
How boring should your team's codebases be
101–110 of 235 posts
Re: How boring should your team's codebases be
#102Earlier quoted context omitted.
Didn't say it was a walled garden. But management has its own ways and quirks I said it was possible that the situation was seen by mgmt as a walled garden. Seen as.
And I answered to that already on my second paragraph. Taking the nuclear option after merely "seeing [something] as" risky without exhausting the much-cheaper remaining options is not "somewhat understandable, if not plain reasonable" . And it's not "ways and quirks": it's incompetence at best or corruption at worst. This kind of situation might be common, but it is not understandable nor reasonable.
Seems like you are the one being uncharitable.
For better or worse there are tons of both reasonable and unreasonable factors as to why a large company would replace a part time developer's side project with something that costs 9 figures.
You don't know those reasons, the person you replied to doesn't know those reasons, and in fact the OP probably doesn't even know those reasons (they "used to turn up to that customer annually for maintenance").
Re: How boring should your team's codebases be
#103Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any s…
>> deployed to over 2000 locations
Were there 2000 independent systems / SQL server instances running or just one? 2K separate deployments to manage (with 1K users each), does sound a little scary. Of course, perhaps that is not what is going on at all.
Re: How boring should your team's codebases be
#104There's never a simple answer to this. Here's some of the things we encounter: * A bored developer is an unhappy developer. Unhappy developers leave. Developers that leave take a swathe of domain knowledge with them. * Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what…
> A bored developer is an unhappy developer. Unhappy developers leave. Software development is the only profession where people expect (and demand) to have fun at work. The official ways of this society is that fun is what your free time is for, and work is for getting things done and make money. Why is this different for software development? Why do people think they can "play with new technologies" at work, which i…
Dunno where you're from, but where I'm from, it is pretty much the opposite world. You're a red flag if you don't see yourself as having fun. Yes, this includes most webdev shoves where one does the equivalent of shoveling virtual manure. (No, I don't agree with this, either).
>Why do people think they can "play with new technologies" at work
Because software dev is a step above code monkeying and people value being able to grow. Which requires experimentation.
It's unprofessional when there are higher priorities or you can't make a potential business case.
Re: How boring should your team's codebases be
#105Earlier quoted context omitted.
> What was the reasoning provided Reasoning? Hah-ha. Haaaaa... It was an open government tender process, for which I, or the company I worked for was not eligible, despite the tender being "open". You see, a decade-long pedigree of actually having implemented the software used for this purpose did not qualify us for replacing it with a v2.0. There are rules , you see? They have to be followed! Or else. Or else bad th…
I think most readers, including myself, empathize with you and understand the frustration and absurdity. But you are also telling just one side of the story (yours) and I imagine that v.2.0 specs had certain requirements and features, possibly required by legislation, that needed to be followed and implemented. When you say, dismissively, There are rules, you see? They have to be followed! that's when I, and likely o…
Nah, this is full story 99.9% of the time. I worked for government and this happened all the time - nobody ever got fired for choosing 500x more expensive IMB general solution versus something that you customized for the stakeholders and has 0 issues and million users and 0 incidents. I had personaly many such products being on the side of the government once, and on the side of the private vendor after that.
One example - I created Help Desk system for the public finances of entire country using Redmine and other FOSS tools. The cost was 0, the time to implement it was single year of not so focused work and it served hundreeds of thousands of people. Then IBM took over with its service desk, implmenting it for years and costing infinity. They could get into tender, I could not since I and my team are small company. The funny thing is that stakeholder subteam abandoned it and returned to my solution (with 0 maintenance since I left the company).
This is typical. You need to know how government works to understand it. I understand it, but do not approve it. I am also not frustrated about it, its just how this world works currently, in majority of the countries as far as I know.
Re: How boring should your team's codebases be
#106Earlier quoted context omitted.
You must have only ever done minimum-wage unqualified work to be saying that. Everyone wants a job that they love, and that requires having fun at work. People leave jobs, any kind of jobs, because they're bored and not having fun.
Do you really think they take into account in other fields, that their doctors, lawyers, finance people etc should "Have fun" and change their decisions away from what is straight forward solutions, because of that? They don't. Only in software. I had a heated argument with a colleague who was fighting to use MongoDB for a new project, even though there was a company wide decision by upper management to NOT use Mongo…
This isn't true. Developers like tinkering with new frameworks. Doctors like experimenting with new treatments or procedures or drugs, often very immature and untested. Lawyers will seek opportunities to flex a new legal strategy or argument in order to make a name for themselves or to impress a judge, even if it may not be the safest strategy for the client. Finance people do just about anything to avoid simple, straightforward, time-tested investment strategies.
Re: How boring should your team's codebases be
#107Earlier quoted context omitted.
> I would prefer to work on a codebase that solves problems effectively than a codebase that is novel. I have a design for a very very boring code base that involves no frameworks or external libs. It works fantastic and has been used by some of the most productive teams I've managed. Those teams can manage "more services than we have people on the team by a scale of 2-4x" (quote from one of the engineers on one of t…
Is it open source or only available to clients?
I think I grossly oversold this thing because there's a lot of comments here asking for something.
I don't really have this concept written down anywhere like a number of other ideas I have. But, I guess the short version is, if I had to make an elevator pitch or something: No framework is a configuration (maybe "distro" in the linux sense) of concepts (maybe "packages" in the software sense). A concept is either something you might use a framework or library for (and usually it exists somewhere), or it is something you would want a linter to find, and it might even be something that you want to ensure was done correctly at code review. I think this last one is the most accurate idea of what a "concept" is.
Over time I have accumulated a small informal set of "packages" that can be implemented without a helper library in nearly the same amount of code as if you were to use that library anyway. The important part is that the running software doesn't depend on the third party code, but actually the developers depend on a rule book and anything that violates the rules should be treated the same as calling an third party package's API method that doesn't exist. In other words: the dependency remains entirely in concept-space, not disk space.
This link below is not "no framework" but it is something I wrote where you can see the result of "no framework thinking". The concepts are stole from people who are probably smarter than me, have decades of experience and written books on these topics. The only difference is instead of turning it into a library to depend on, it's turned into rules for humans (which I guess is also what the book authors originally did anyway). I combined them and made them into a "distro" and I called it "modular provider architecture" (not very engaging or entertaining, but it does what's on the label).
- https://github.com/Incognito/python-architecture-linter/tree...
That text document is meant to be an example of how developers should write an application. By the way, it has a demo application here which does basically nothing:
- https://github.com/Incognito/python-architecture-linter-demo...
It might be hard to see here because it's pretty silly example, but I managed a small/growing team of 3-5 developers who create over 15 different services following this pattern. They did end up using libraries to do things like send data to/from Kafka or a DB, but the Modular Provider Architecture's rules were always there.
Oh, by the way, that repo I linked to, https://github.com/Incognito/python-architecture-linter/ ... this is a proof of concept for a linter that could implement the "no framework" concept. It is a dev dependency of your project, meaning you have no production framework as a dependency. It is a tool that lets you configure "rules" for your project in the style of any linter you already know of. It's like a linter from hyperspace, you can "lint" rules like.... if a file is 3 levels deep, and depended on by methods anywhere in the project with the word "bob" in the method name name, but those methods don't have if-statements, and also the Afferent coupling of the module itself is less than 0.5 .... fail CI with an explanation why. It also has a feature for you to commit an exemption list.
I used this in my teams once I started managing multiple large teams, and I could do things like generate entire reports across all projects of these really complex metrics that most linters and tools aren't really set up for.
That code is in these files, sorry for the total mess, I was just hacking around and didn't really think of a nice way to structure the definition "API. My main goal was proving the concept.
- https://github.com/Incognito/python-architecture-linter/blob...
- https://github.com/Incognito/python-architecture-linter/blob...
====
So, to summarise:
- "Modular Provider Architecture" is a "Distro" of "No Framework". Others can exist.
- "Modular Provider Architecture" is composed of "concept packages". Many of those packages have actual software libraries as alternatives. Others do not because they are rules about how to write code.
- Really complex ideas in "Modular Provider Architecture" can be enforced via CI.
I think the "beautiful" thing (if you think sofware can also be art), is that there is a clear an obvious structure to the project, but the "framework" is entirely ephemeral, just like types in typescript.
I guess the really important thing here is: enforce your architecture's rules and pick them very carefully in concert, not in isolation.
====
By the way. That's one idea I have for removing dependencies on frameworks. I also have a really crazy idea for eliminating the need for most software by replacing semver, but it takes me over 2 hours to explain it (I have really bad video recordings where I try).
Re: How boring should your team's codebases be
#108Earlier quoted context omitted.
> What was the reasoning provided Reasoning? Hah-ha. Haaaaa... It was an open government tender process, for which I, or the company I worked for was not eligible, despite the tender being "open". You see, a decade-long pedigree of actually having implemented the software used for this purpose did not qualify us for replacing it with a v2.0. There are rules , you see? They have to be followed! Or else. Or else bad th…
Government software contracts are never meant to succeed. They are meant to burn as much cash as possible. Everyone I know who has worked in Arlington has the same story. Huge headcounts. Billable hours. Literal coked out VPs on yachts.
This is too simplistic view of the state of the affairs.
If that was so, countries would not work at all. There is always a service that needs to absolutelly work, or your government is fucked and lots of its people. For those projects you absolutelly need to hire those that will provide desired outcome without failure. Most of the services are not so crucial and in those you can have such failures without much of a problem, it even seems "good" sometimes as you must employ number of people to fix service mistakes constantly.
Re: How boring should your team's codebases be
#109Every time this topic comes up, it reminds me of a web app I wrote back around 2007 that was deployed to a over 2000 locations. I deliberately used "boring" technologies. The entire front-end used under 100 lines of JavaScript. The backend was simply SQL Server, and the queries were written in SQL instead of some ORM. The output was just HTML. No special tooling was used, no "minification" or "tree shaking", or any s…
It is also possible that this project and you being the only one handling it were analyzed as a risk. It doesn't justify how the handover/rewrite happened, but why it did is somewhat understandable, if not plain reasonable. Typically, employees with walled gardens (willingly or not) are a massive liability to their company.
>"It is also possible that this project and you being the only one handling it were analyzed as a risk"
If that was indeed the case then hire a "backup" person. Way cheaper.
Re: How boring should your team's codebases be
#110Earlier quoted context omitted.
Nowhere in the grandparent's post says that it was a "walled garden", or even that it was closed source. The fact that only one person was needed doesn't mean there's only one person available. OP even said he worked for a company in a reply. The rationalisation automatically assumes that the grandparent is either incompetent or lying by omission, which is very uncharitable. Even if all those problems were true, if i…
Didn't say it was a walled garden. But management has its own ways and quirks I said it was possible that the situation was seen by mgmt as a walled garden. Seen as.
>"Seen as"
Without understanding that it can be simply and cheaply fixed by training second person is gross incompetence. Those single cell morons should've been fired instead.