111–119 of 119 posts
Earlier quoted context omitted.
Compatibility with C and its toolchain.
I think that's a weak response. obj-c was just as compatible and a far less horrible language design.
And it also suffers from the same issues that pollute C++'s design.
Earlier quoted context omitted.
Another possible conclusion from your analysis is that a proper architectural separation of concerns (which could allow one to bang out code like he's still on that plane) has not been practiced in Windows, and by the time Bill was offered the opportunity to code something in Windows it was already hopelessly entangled.
Not exactly. I am a huge fan of code modularization, but what modularization offers you is the ability to decrease the exponent (i.e. to be devTime^1.01 instead of devTime^2). Some features though (including segment tuning, from the sound of it), will touch a ton of other features regardless of how well you modularize your code. I work at a networking company (Arista), and a lot of the interesting problems come from…
Thanks, carry on. ;)
Earlier quoted context omitted.
I once worked with a founder who would always pull that kind of garbage: "I wrote [simple software with no dependencies or integration requirements] in [N] days! Why is it taking you guys [M] months to write [complex software relying on several 1st and 3rd party libraries, a component that needs to work within a large, old legacy system]? Good on the develop manager!
Heh, reminds me of a boss that criticised my work a few months back: Boss: "Hey antimagic, why haven't you finished that module yet?" Me: because the code it's interfacing to is a big ball of spaghetti (paraphrasing, because it was the boss in question's code - so I was much more diplomatic) Boss: "You need to learn to be able to work with other people's code better - I can get in and modify your code easily" Me: ...…
Earlier quoted context omitted.
On the opposite site of the coin, I was a professional developer 25 years ago (and still keep my hand in as a hobby), and do regularly struggle to understand why things take as long as they do these days. We were quoted a day for something that I said could be written in about half an hour - their quote included nothing more than coding and unit testing it. So I was challenged to prove it. Which I did (or rather I di…
Times have changed considerably. When I started in the industry 20+ years ago our tools were a compiler, debugger, and editor. Any library not provided by the compiler we wrote simply because purchasing libraries was very expensive. We also weren't afraid to code a solution specific to the problem and not be overly concerned with abstracting every library for potential use with any future application. Most work went…
>We also didn't worry about clustered environments, asynchronicity, or concurrency.
Clustered environments, probably not. But asynchronicity and concurrency were the bane of my life. Writing comms software back in the day involved having to hand-craft both the interrupt-driven reading of data from the i/o port and the storage and tracking of that data in a memory-constrained queue, synchronised with displaying that data on the screen. And the windowed UI had to be hand-crafted as well. Error handling was no more of an afterthought then than it is now - and you couldn't roll out a patch for a minor defect without manually copying 500 floppy disks and posting them to clients.
I understand why some bits of development take a long time, but the reality is that 90+% of the development work that our place does these days is what an ex-manager used to refer to as "bricklaying" - dull and repetitive work that involves pretty much zero thought to implement. Extract file X (using the language's built in drag and drop file-extract wizard), sort it by date (using the language's built-in sort module), split into two separate files (using the language's built-in file split module) and load into database Y (using the language's built-in database load module).
And even with all of these tools, it still takes 10 times longer for people to develop these kinds of thing than it did when we were writing all of this from scratch. It's not because of complexity of coding, of environments, or of frameworks. The problem is that much of the IT industry has replaced skill and knowledge with process, contracts, documentation and disinterested cheap labour.
Earlier quoted context omitted.
On the opposite site of the coin, I was a professional developer 25 years ago (and still keep my hand in as a hobby), and do regularly struggle to understand why things take as long as they do these days. We were quoted a day for something that I said could be written in about half an hour - their quote included nothing more than coding and unit testing it. So I was challenged to prove it. Which I did (or rather I di…
I have been developing software for 20 years and I am currently replacing some applications that were written in the last five years. They use OOP, patterns and the latest tools. Often I wade through dozens of lines of codes trying to find the meat of what they are trying to do. I usually find easier and shorter ways to implement the same thing just by better design and avoiding repetition. I don't think programming…
That really shouldn't be true.
A pattern is simply a commonly used way of solving a common problem. If you're picking one that make it more complex, then you've picked the wrong pattern. The reason that I could do the example I talked about in my original post in 10 minutes was because it was a bog-standard design pattern designed to solve exactly the issue that the software needed. Amongst the many reasons why it took the developer 2 days was the fact that they had to pretty much reinvent this pattern from first principles.
Equally, if you're introducing a tool that doesn't simplify something that you'd need to do/build manually then you shouldn't be introducing that tool.
Earlier quoted context omitted.
Also I've generally found it's easier to develop starting with a blank directory tree (no code), than to inherit a legacy codebase, have to make the sometimes grueling time/energy/focus/trial-and-error investment needed to come up to speed on it, understanding-wise, at the fine-grained level of detail you need to code confidently, then, figure out how to make a positive change that doesn't make some other thing worse…
Of course it's always easier. The question is, can the business afford to wait while you greenfield another app? Usually it can't. That's why refactoring. First step is fixing the development environment / build process and getting a staging server up. It will inevitably be broken / nonexistent, with frequent edits directly to production necessary. The last guy will have internalized a great deal of operational worka…
When he says "He wrote FAT on an airplane" he means with pencil and paper since FAT is so old that there were no laptops to do that on. Which maybe he figured out all of the specs, but he didn't put code down and debug it. Of course in those days writing it on paper was quite common before people typed it into the computer. And that is quite impressive in and of itself. Most of the time people treated that activity a…
Coding is something you do in your brain, not in an editor.
Earlier quoted context omitted.
Of course it's always easier. The question is, can the business afford to wait while you greenfield another app? Usually it can't. That's why refactoring. First step is fixing the development environment / build process and getting a staging server up. It will inevitably be broken / nonexistent, with frequent edits directly to production necessary. The last guy will have internalized a great deal of operational worka…
What do you do when management won't allow Unit/Automated testing because it takes time away from writing user facing code?
The reason your boss is saying no is because you had to ask him. The reason you had to ask them is because you know it will take more time than it will save, at least at first.
You have to learn this skill somehow, and the best way to do it is on something that matters rather than with a side project. So write tests at your job, and learn the skill of testing on your employer's time, without their knowledge. Or on off hours if that makes you squeamish. But learn the skill, it's important.
Then, when you refine your testing work flow to the point where it makes more sense to test as you write, don't bother hiding it anymore. When they ask, show them your workflow and how it's not taking up too much time and list out the benefits of testing. If they tell you to stop anyway, take your new skills and find a new job. You're growing past the ability of your current job to challenge you.