141–150 of 179 posts
Religion implies dogma, and I don't like dogma in my field.
Side note: the biggest takeaway for me here is: be careful when writing such self-confident articles. The general public doesn't take kindly to such displays.
Earlier quoted context omitted.
The message I took from this article was minimalism in features and not necessarily code. And certainly not about library usage. If you're building a product, focus on building a few key features extremely well. I suspect that part of the reason for feature bloat is that a when product is assigned dedicated, long-running teams, it tends not to reach an 'end state'. The team would rarely say "okay, now the product is…
Microsoft applications released as store apps were an attempt at minimalism in features. Their music, skype, mail, even the control panel replacement "settings." Windows 10 has been cutting features left and right. To Microsoft, minimalism means: Rebuild a popular piece of software from scratch Release the NEW improved shiny app that follows a new design fad. Gloss over the fact that it's unreliable, slower, more cra…
The argument against Entity Framework, and for micro-ORMs. - https://pknopf.com/post/2019-09-22-the-argument-against-enti...
You don’t need Cake anymore; the way to build .NET projects going forward. - https://pknopf.com/post/2019-03-10-you-dont-need-cake-anymor...
My blog is also written from scratch, using a stupid tool.
https://github.com/pauldotknopf/pauldotknopf.github.io/tree/...
Earlier quoted context omitted.
Yeah, I came in here to call out the error tracking use case...a good error tracker needs to do a _lot_ more than that.
I suppose your requirements are different. We want to deal with errors like we deal with inbox, fix issues until we have "inbox zero". On our case that is all the client we need. There's obviously more logic on the backend, but not much.
Earlier quoted context omitted.
The message I took from this article was minimalism in features and not necessarily code. And certainly not about library usage. If you're building a product, focus on building a few key features extremely well. I suspect that part of the reason for feature bloat is that a when product is assigned dedicated, long-running teams, it tends not to reach an 'end state'. The team would rarely say "okay, now the product is…
Microsoft applications released as store apps were an attempt at minimalism in features. Their music, skype, mail, even the control panel replacement "settings." Windows 10 has been cutting features left and right. To Microsoft, minimalism means: Rebuild a popular piece of software from scratch Release the NEW improved shiny app that follows a new design fad. Gloss over the fact that it's unreliable, slower, more cra…
Small case in point - the search bar in Excel 365. Until recently it was a text box next to a magnifying glass, and you could type into it.
Now it's just a magnifying glass. You have to click on it to reveal the text box. Only then can you type your search term.
This change produces absolutely no user benefit. There is no rational reason to add an extra click. Long-term users now have to go through "Wait, what...?", where previously muscle memory would just work.
Another example: the AutoSave switch in Office 365. Users quite understandably assume that "AutoSave" means the file is saved automatically.
In fact this is a OneDrive-only form of AutoSave. AutoRecover - a different and much older local drive auto-save feature - is unrelated, and has a separate setting in Preferences.
Providing a minimal switch in the UI which doesn't mention the distinction is guaranteed to confuse anyone who doesn't already understand the difference - especially when clicking the switch tells you AutoSave isn't available because of your privacy settings, and doesn't mention OneDrive at all.
There's an old quote I can't remember the exact source of, that "Microsoft Word users only use 5% of its features... but each user uses a different 5%."
It's not bloated. It's just that other users have different needs from yours, and you're ignoring other users, assuming they're the same as you. But they're not.
It's easy to write a minimal version that works on your dev machine in your browser. But now get it to work on all browsers on all devices on all OS's. And now build in all the little feature that big clients require for legitimate reasons. And now ensure it works with several legacy versions of API's, etc. Is it "bloated"? No. It does what it needs to do.
Earlier quoted context omitted.
I deal a lot with white box networking hardware and software and have never encountered this bug. Can you point me to some more info? Thank you.
See "ixl_detect_sparse()" in the FreeBSD ixl driver: https://svnweb.freebsd.org/base/head/sys/dev/ixl/ixl_txrx.c?... Or __i40e_chk_linearize in the Linux i40e driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... And their 100g NIC has the same bug (at least according to the FreeBSD driver that's in review now). ARGH!
Earlier quoted context omitted.
There is indeed a fine line between NIH and minimalism. They have a strong correlation. You have to compromise between unnecessary features/bloat/crap or simply do it yourself. It's often surprising how easy it is to make something from the scratch. Hence NIH.
It's not that fine a line. There's tons of space in the middle and I find a steady supply of coworkers who love to write code and hate to use libraries who never bother to understand half of what the libraries they do use are capable of. I may be slightly unusual in my habit of trying to find new uses for the tools we already have, but I'm not abnormal. This is something mature people should be doing as a matter of c…
Earlier quoted context omitted.
I suppose your requirements are different. We want to deal with errors like we deal with inbox, fix issues until we have "inbox zero". On our case that is all the client we need. There's obviously more logic on the backend, but not much.
Yeah it needs to do that, but that likely means that deploying a particularly egregious bug will fill your inbox with repetitive and useless data. It should also give you information on the current user, the browser, locale, etc. None of that extra stuff is really extra, it's critical for quick debugging. It's also hard to get right, and doesn't preclude inbox zero in any way.
Earlier quoted context omitted.
The message I took from this article was minimalism in features and not necessarily code. And certainly not about library usage. If you're building a product, focus on building a few key features extremely well. I suspect that part of the reason for feature bloat is that a when product is assigned dedicated, long-running teams, it tends not to reach an 'end state'. The team would rarely say "okay, now the product is…
Recently, on my first software job (freelance) I messed this up. I had very little opportunity for contact with the client and they were slow and unreliable with providing feedback. I could tell we would go over schedule if I didn’t produce a lot more work with each feedback cycle and I desperately wanted to do a good job so I let myself get weighed down with imagining things that they might think I was stupid for no…
It is the power base of personal change.
2. It's ok to make the client responsible for everything in writing. Especially if you do not have a deep committed relationship with them.
I have clients I have worked with for over 15 years and they don't even need a quote from me to start work, and they send me a check for any reasonable amount up front.
I have other clients where I spell out every single detail before I start and I do not deviate (add or subtract) from this list (for both our benefits) without written request from them and possibly a fee change.
3. I give away free work to many clients for many reasons. Some I don't even let them know, and others I make sure to put it on the invoice as a discount and rate. This way they know that I did the work, I did it for free, and they should recognize that. Also so that it's easy to charge for this work in the future.
A lesson I learned hard was a few failures:
1. When to start: I did a bunch of work when a client said ok on the phone. When I invoiced he was mad because he didn't remember saying "ok" to start work. So, now I only start work with an email record, period. Even if it's annoying, even if it delays work, even if it makes the client annoyed. Every single time I ask "can you send me an email with the ok to start this work?" (or I prompt them with an email and they reply) Again, some clients verbal is ok, but only if I know them really really well. (ie, lots of previous work with them)
2. Extra work: I did a bunch of extra work/features on one project, and they wanted me to support the extra work also for free forever. (forever... sigh) And were angry when I said I couldn't...
3. Accountability for timelines: I had a project that every weekly meeting more features got added to the project. We spent half to over half our budget in meetings. (yes that bad) So I made sure to document all time spent on everything one month. The next month the lead project manager started cutting back the meetings instead of us devs complaining about not having enough time, the project manager _knew_ we didn't.
4. Specs and Expectations: Numerous times I "imagined" what the client actually wanted because I knew better than them. I would build something expecting to be paid for it (or at least appreciated) and it would be presented and the client would ask for it to be _removed_ from the project.
This was the last kick in the teeth I would ever take from this, ever, ever again.
Then later a new client (a state university) had visual layouts of interfaces given to me. I had learned some lessons about being screwed over before, so I was going to stick to their layouts no matter what. After it was built, they were _really_ pissed, and had the gaul to say to me:
"Why did you build it this way?" And I said "Because it was how it was designed and specced out". Their reply?
"That isn't what we wanted, you were supposed to make what we wanted."
Unreal, but I won this argument hands down. No one can read minds and people who expect you to don't have a reasonable argument if you provide your experience on why you will never do this again. What can they say to you?
My long term clients _never_ give me a hard time about anything extra I do, ever. I know them, they know me and they say "make something that solves this problem the best way you can", and we may tweak, but we respect each other and I fix my errors, and they pay for theirs and we meet happily in between no matter what.
Also, I will no longer support software for free indefinitely, I say I offer free bug fixes for 6 months. Any new features is paid work. And support after 6 months will need to be negotiated. (all this depending on the client and project)
I state as much as possible up front about everything (in writing) so there are as few arguments as possible (I hate arguments with clients they really suck). Doing this extra work kinda sucks sometimes, but the older I get the less I have to do this. The first time it saves your ass you will be happy. And as soon as you write it and hand it over you will have instant peace of mind.
It may take you a few projects to get the handle of these ideas, but it's obvious you recognize there is a problem. But communication and clear expectations is the solution. I have also learned to say "Sorry, I meant to state this up front, I failed to do so, so I will give you X for free for my screw up, but I still need Y to do Z"
Keep at it, what you are facing is normal, and your desire to do good work is commendable and will pay off in the long term in ways you can't imagine.
Cheers!