Where’s the course on managing your reaction when the client starts moving the goal posts on a project that you didn’t specify well enough (or at all), because you’re a young eager developer without any scars yet?
Back in the 90s, this was actually a sneaky part of Dartmouth's CS23 Software Engineering course. At least half your grade came from a 5-person group software project which took half a semester. The groups were chosen for you, of course.
The professors had a habit of sending out an email one week before the due date (right before finals week) which contained several updates to the spec.
It was a surprisingly effective course.
(Dartmouth also followed this up with a theory course that often required writing about 10 pages of proofs per week. I guess they wanted a balance of practice and theory, which isn't the worst way to teach CS.)
In uni we had a semester long group project with the stronger coders as project leaders. Group leaders controlled pass/fail for the group members and vice versa. After the leaders put together project plans for their teams and everyone was supposed to start working WHOOPSIE reorg and all the leaders got put on random teams and new people got "promoted" into leader (of groups they didn't create the plan for). If the project didn't work at the end the entire group failed.
I've never been taught anything more clearly than the lessons from that class.
Shit I was thinking about exactly the same thing: professor deliberately change requirements at last week to mess up the students and give them a bit of taste of true work.
My uni kind of had that course! They just didn't tell us what it was going to be ahead of time and it was horrendous. We all absolutely hated the professor but it was required to graduate so we all came up with various coping strategies and at the very end he said "congratulations this is what the real world is like!"
(I didn't believe him at the time, but in some ways he really didn't go far enough...)
This is interesting. I’m wondering how programmable this is. Would this project (or any similar ones) be able to POST a json payload with a field set to “now()”?
About the poor memory stuff, just get it in writing. “In writing“ could mean in an email, or a chat, or more likely in an issue tracker that has an audit log. When there’s a discrepancy, just link to where it was written down.
I like this mentality, truly, makes perfect sense. Check in often to make sure you’re building the right thing. Keep going until it’s done.
However, the client is going to want to know (A) how much it’s going to cost, and (B) how long it’s going to take. These are extremely reasonable questions in most cases/industries. To answer these questions with a shrug is a nonstarter. The client is working with a time budget and a financial budget, and they need to have some sense of the numbers.
If the Waterfall and Agile methods are opposite ends of a spectrum, somewhere in between is where I’ve found an acceptable middle ground for both developers and clients.
Problem is that you can budget time/cost of endeavors that were already done.
If you are doing R&D that is not something you can budget because definition of research is you don't really know what you are searching for - well you have to have some reasonable idea of course but if $20k becomes suddenly $50k that should not be a surprise for R&D.
People might say "but the CRUD app you are building is not real R&D" if you are really building a CRUD app that is like an existing one - setup Wordpress, SAP, Shopify or pick from dozens of existing ones and be done with it. All else is R&D because there is more unknowns than known stuff, there are always integrations with 3rd parties, some workflows that need implementations etc. .
Even building a piece of road - well all tech is there - can end up running over time/budget if for example you find terrain under is not as one expected and it sinks or something and you have to figure out how best to deal with that and there is no expert to deal with that specific type of ground you ran into.
I was quoting from the article, which, admittedly, isn’t straight from the horses mouth. If there’s a discrepancy, one of them is wrong (I think I know which).
> While there’s no display, the illuminated ring behind the grip does provide a visual indicator of what the iron is doing: solid blue means it has power but the heating element is off, a pulsing blue indicates the iron is heating, and orange means it has reached the desired temperature. If you flick the heater switch off, the ring pulses purple until it cools back off and returns to blue.
Looks nice, both the site and the app! The first thought I had though was, here's a central place where potentially hundreds, thousands, perhaps tens of thousands (or more, depending on how successful you are) of database credentials are stored. Your https://visualdb.com/datasecurity/ page says "Database credentials are encrypted before being stored" but how do I know that? Encrypted how? This equates to "I pinky promise I won't get hacked, and even if I do, all your passwords would be impossible to crack anyways". Security-conscious users probably will need a bit more than that. Any thoughts on using other authentication methods?
Edit: as other commenters have mentioned, an on-prem version would certainly ease concerns a bit.
Don't store database credentials at all. Ensure your product and recommended database configuration supports SSO/SAML/etc with credentials managed through Okta or Active Directory. You'll need that if you go up-market into an enterprise.
You can't store database passwords as hashes, because you need the clear password each time to connect to the database. Really, the only way to guarantee security is to use air-gapped systems, in which case you only have to worry about guarding physical access. See https://www.nextgov.com/artificial-intelligence/2024/05/micr...
> getting people to use even the first layer of threads is very difficult, especially non-technical people
Indeed. We use Google Chat which is roughly a Slack clone in terms of structure. A discussion will start at the root level, and then branch into a thread after a few comments, but some users will miss this and continue to use the root level, which of course gets mixed into unrelated comments. It’s easy to create a mess, and it’s even worse when a discussion has multiple threads.
This “thread-based” style of space/channel was forced upon Google Chat users late last year. Prior to that, we had the option of “topic-based” channels, where every discussion had its own thread and there was no root level. Any reply to a topic would bump the topic into view. These were great for some use cases (one topic for each software issue, one topic for each support case, etc), and were easy to understand for non-technical people, because you could explain it like “each topic is like an email chain”. We got into the habit of summarizing the first comment of each topic, which always remained visible, so you could browse the list of discussions, again, much like email.
Anything that you can relate to email is great for the non-tech crowd.
> companies that offer a free service but start charging once they've locked in a client-base (I'm looking at you Heroku).
I don’t know much about Heroku, or if it’s been enshittified (yet?), but a company that offers a free product and somewhere down the line starts charging for it sounds fine to me.
And anyone who believed a product produced by real people working at a real company could be free forever was kidding themselves.
(In general though I agree with the sentiment of the article.)
