Keep it simple stupid and focus on the end product - that's all you really need to know
The Duct Tape Programmer
31–40 of 53 posts
Re: The Duct Tape Programmer
#32'Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t goin…
"I think both the duct tape engineer and his opposite are both extremes to be avoided most of the time." Very true! Everything in moderation.
My first job in software development was addng features or fixing bugs in Drupal sites built by people who had left the company. These were fantastic engineers, but I pulled my hair out every day and fantasized about unit tests, documentation, or even a clue about what was going to happen next.
Even with unit tests today, I still make mistakes -- sometimes big ones. But I also recognize that for software edifices to survive, you have leave a solid foundation for others (or your future self) to build on. Too much engineering and there's company left to employ you. Too little and the product might ship but it doesn't work.
Re: The Duct Tape Programmer
#33The title could use a "(2009)" - I thought this was a new joelonsoftware article.
ditto! I was disappointed not to have fresh meat myself.
Re: The Duct Tape Programmer
#34Right now I'm working on save/load for a game that is overflowing with duct tape code. Yes it shipped and did well. But now I'm paying for all the sins of all the duct tape used by all the coders. I'm not sure I'd change anything in the past but I do reserve the right to bitch about things written that aren't fully correct but close enough... until save/load is considered and then it just doesn't work at all. Grumble…
For all the naysayers, I think you're right to be disappointed that things weren't done better. It'll drive you to become a better engineer and spend a little (but hopefully not too much) time building things when it's your turn. Also, don't grumble too loudly -- you still have a job :-)
Re: The Duct Tape Programmer
#35The problem with this blog post is that it's long been used to justify writing crappy code, when it's actually about writing simple code, and those aren't necessarily the same thing. If your duct-tape go kart falls apart going around a corner and gives you a permanent injury you're gonna wish you spent a bit more time at the starting line wondering what to build it out of.
Since I moved into a lead role (where I still do day to day coding but don't do as much as my reports), a good rule of thumb for me has been that if I can't track down the offending line of code within half an hour based on a stack trace coming in from a significant portion of end users, someone has overarchitected something.
Figuring out when something is too simple is trickier, but it tends to be pretty obvious because a ton of bugs come in that are easy to locate.
Over the past few years, I've decided that as a general rule I prefer engineers that under-architect to those that take it too far, because the damage is far easier to mitigate...
Re: The Duct Tape Programmer
#36The problem with this blog post is that it's long been used to justify writing crappy code, when it's actually about writing simple code, and those aren't necessarily the same thing. If your duct-tape go kart falls apart going around a corner and gives you a permanent injury you're gonna wish you spent a bit more time at the starting line wondering what to build it out of.
a hundred times this. Technical debt is painful on all levels. It makes things falling apart more likely, it makes refactoring more painful, and it adds cognitive load.
The argument that you can absorb technical debt only really works if you plan on an aquihire to save yourself, because if not it's very likely you'll have to clean it up (and you'll have paid a decent amount of interest on it).
It's not like good code and code that's easy to write are two ends of a line.
Re: The Duct Tape Programmer
#37As a programmer who is too often focused on perfection, yes.
Re: The Duct Tape Programmer
#38Multiple inheritance often makes it extremely difficult to tell where my code is coming from. When you don't use inheritance, you often get to refer to another module by name . E.g. `my_dependency.fetch_data(123523)` With multiple inheritance, however, that other module has become your own "self"! Suddenly you're stuck with: `self.fetch_data(123523)`. And if you want to find the source of `fetch_data()`, you basicall…
>Multiple inheritance often makes it extremely difficult to tell where my code is coming from. Thus the rise of the "can't do anything without an IDE" developer ..
What exactly is the problem with IDE's?
Why should I have to learn a hundred cryptic keyboard shortcuts to get what I consider normal functionality? I have in the past used Perl's command line debugger. Why would I want to do that when I have a far more efficient graphical debugger in Eclipse?
I work with bioninformaticians, and many of them are too lazy to have ever set up an IDE. Most of them won't have had autocomplete until Kate included it. Barely any of them uses a step through debugger. Its like a revelation when they ask me for help and I show them it on my machine.
Re: The Duct Tape Programmer
#39I have started taking "I write bad code", "I don't write unit tests" etc with a pinch of salt. I think in any real world scenario there will be factors that pull the code in one direction or the other. Sometimes the most important thing is to ship, sometimes the most important thing is to ensure that you can keep shipping. It is entirely contextual.
Exactly.
I build and manage an in house database. The data model changes frequently. I have started adding in unit tests in the past, but they are rarely worth the time (in these circumstances). I estimate that creating unit level tests and fixtures would probably treble the time needed for features, and would catch maybe 10% of the bugs that appear.
Uses request a feature. I build it. I show them, ask them to test it and tell me if they have a problem. I get plenty of testing done. Just not in the unit test way.
Now I imagine if I had an online app used by millions of people and I was doing a big upgrade I would have a different attitude towards the way I test.
Re: The Duct Tape Programmer
#40Earlier quoted context omitted.
I'm on the other end of it with my current project. The "architect" managed to wire about a dozen third party libraries and frameworks together to create a Frankenstein monster that's quite literally unmaintainable. Every day is a new day of Jenga - touch anything and it all just collapses. The funny thing is it didn't save time at any point in the project. the learning curve to configure all that was so steep we cou…
I feel for ya. People often rail against reinventing the wheel, but 36 times out of 37, I'd rather have an in-house created wheel that rolls how we know it should with code we understand than some 3rd party bag of voodoo that supposedly roles in the desired ways, maybe.
I would far rather have something put together with well known, documented, tested third party libraries than some undocumented in house crap that one "superstar" developer knows how to work and no one else.