I hate this forum software. It just ate my post.
Summary:
If you've got bad programmers, nullify them or make them better (both can be hard, I know).
Traditional big-design-doc methodologies clearly aren't working to make poor programmers produce good code. Agile methodoligies won't either. I think it's impossible to get good code from poor programmers. You'd do better to have them sit in the corner while the above-average programmers do all the work.
I agree that it is hard to hire good programmers. I blame the schools. (Seriously.)
Posts made by Jorg
-
RE: Does Agile work for standard software development
-
RE: Rational agrument against Hungarian notation?
@Hubert Farnsworth said:
Try naming a class "Controller" there and it'll propose
"ontroller.[h|cpp]" as file names. Sick.
Blech. That's some really obnoxious behavior.
Prefixing classes with C makes no sense. (I'm gusesing that) Microsoft only did it to avoid naming conflicts (since they either chose not to use namespaces or they weren't yet available). And of course, now Microsoft alone has three different CString implementations. Not to mention the million other CString implementations in other libraries/frameworks.
-
RE: Win32 C - append Url to path
@Angstrom said:
You'll need a transformation that mangles slashes:
char mangle_slash (char c) { if (c == '\\') return '/'; return c; }
std::string path = "C:\\Windows\\"; std::string fragment = "www.example.com/foo/bar"; std::string output = path; std::transform (fragment.begin (), fragment.end (), std::back_inserter (output), mangle_slash);
Completely untested. I've probably goofed up the back_inserter or the forum formatting.
He said he needs to use C, but your basic logic works.
Replacing every character seems an odd way to do a simple replace, though. It's kind of odd that C++ has a transform, but not a replace (in string). Again with the over-engineering.
-
RE: Does Agile work for standard software development
@sniederb said:
How does the development team KNOW if they're going to meet the
delivery date? They'll know around Sep 15, but what about in March 06?
Then, they obviously haven't yet specified what to do in iterations
happening in the summer (otherwise they wouldn't be embracing change),
so essentially they don't yet know what they'll be doing a month from
then.
Now the project manager asks:
- how much work is already done (%)
- are we on track for the delivery date?
In a similar vein, how does any development team ever KNOW if they're going to meet a date? Answer: They don't. Software projects are chronically over budget and past deadlines, because they cannot know when they'll be finished. Instead, they make estimates. This is the case whether the team is using agile methods or traditional methods. A significant part of XP (for example) is dedicated to learning how to better estimate time required to complete tasks. So while XP can't magically guarantee a delivery date, it aims to provide better estimates than traditional methods.
@sniederb said:Take the four variables of XP. If one of the large customers adds
scope, and the team stays the same (and - usually - quality is a
given), then it can only be time which changes. So, does EACH new
requirement prolong the developement process? Does agile mean you gain
flexibility by getting rid of a binding delivery date?
Yes and no. Yes, adding requirements extends the development process. That's just a fact of life, no matter what development process you use. Agile methods can't change that. They can, however, allow you to substitute functionality, basically for free. If you decide that you don't really need feature A, but feature B is vital, you can substitute the (unimplemented) feature A for feature B, assuming of course that they are approximately the same complexity.
In a very similar vein, agile methods allow you to leave certain features ill-defined
until later, with the understanding that a certain amount of time is
allocated to the to-be-clarified features. Of course, leaving enough
time for a simple search and then deciding that you want google
rewritten for this "simple search" is not going to work. Again, you
have to make estimates about what you're going to want; have a general
idea. This isn't precise, but it's better than locking yourself to a
design document and then realizing that the document captures the wrong
functionality. Basically, it allows you to set the scope for a feature without defining the specifics of that feature.
@sniederb said:I'm coming to believe that a software development process applies to
the first 60% of project time, while everyone's still relaxed. When the
late changes start coming in, the binding delivery date is looming and
the bugs just won't go away, it's the time for the GOOD developers to
step in and do their thing. And that is usually not very structured,
but more like sophisticated code-and-fix.
I'd have to agree that this is somewhat true. But that's exactly why agile methods exist. They aim to minimize the problems caused by changes, and maximize flexibility. The last part of development shouldn't be hack-and-go. It should be as thought-through as everything else. That's one of the promises of iterative cycles. Every cycle is as important as the ones before. So the last cycles shouldn't be hacked together. They should be of the same quality as the first cycles.
@sniederb said:A good software development process ensures that the first 60% are so
efficient that above scenario simply doesn't come up? I believe there
is no process to prevent a change request 4 weeks prior to delivery
except telling the customer you won't do it. And too me, that's really
a major thing. This isn't about internal processes, but stepping up and
simply telling your key account that, no, we're not able to implement
this in a few days without compromising quality. And if the competitor
say's he can, then he's lying.
It really depends. If the request is to add, say, a search for accounts by user's social security number, it might be reasonable and easy. If instead, the request is for an entire search infrastructure which doesn't currently exist at all, then it might be unreasonable.
Agile methods aren't magic. Changing things on release day still doesn't work. Agile methods aim to minimize the negative impact of change. They can't always eliminate it, though. They recognize that change is inevitable, so you might as well expect it. They also recognize that change can improve the product. If the client needs something he didn't originally expect, why not give it to him? (Possibly at the expense of other features he decided he can do without.) It results in a better product, a happier customer, and possibly a repeat customer.
- how much work is already done (%)
-
RE: Another question for the database gurus out there
Why do you need this functionality at all? I pray that this isn't supposed to be some kind of security, because if so, you need to revisit your entire plan.
I can't envision a system in which random numbers in the url are fundamentally better than sequential numbers in the URL. -
RE: I don't wanna create a WTF.. database question
@t-bone said:
true but in this case it's a case of inserting for example order lines and making sure it's always the same sequence on packing slips and invoices etc, there are not a huge number of records (with the same foreign key to a header table), and there are not a huge number of rearranges. It's to retain sequence after entry
The index method is still safer than the float method. It's rarely safe to assume that number of changes will be small. If the number of items (order lines in your example) isn't expected to change much, then there's no real reason to make it dynamic at all. Put it in a config file. Don't mess with the complexities of a database unless you need them, and if you do need the complexities of a database, then use it correctly (safely). If you build in the capability to easily rearrange items, expect that people will use, and even abuse, that capability. Just because it seems unreasonable to make a lot of changes doesn't mean it won't happen.
I believe that the insert-in-the-middle method with floats could actually run out of precision pretty quickly, too.
-
RE: Rational agrument against Hungarian notation?
@dhromed said:
Of course I know my own code.
You don't make your code understandable for yourself, but for other people and your future self.
It's about the other guy who goes directly to line 258 to fix a bug that occurred at line 258, sees "coordSet" and would like to know what the hell it is.
Though in many cases he can get it from the context.
Sorry, I used you to mean both "you" and "one". The part directed actually at you was a little sarcastic. I expect that you know your own code. As for someone else editting your code, I still stand by the assertion that if one doesn't understand the code, then one isn't safe changing the code. I wouldn't want anyone messing with my code who was so lost that he couldn't (easily) figure out the type of a variable.
Seriously, editting code that one doesn't understand is dangerous. e.g. Let's say the error at line 258 is a null pointer exception. So, the obvious solution is to simply wrap the code in an "if (arrCoordSet != null)" block. Howver, that only works if the coordSet is expected to be null sometimes. If instead coordSet should never be null, then it's a dangerous hack, because now it's just masking the bug, which will likely come back later in a harder-to-diagnose form. That's probably an overly-simplified example, but I think the point is correct. One can't safely edit code that one doesn't know.
-
RE: I don't wanna create a WTF.. database question
@Angstrom said:
I'd like to introduce you to my friend, SQL F701 ON UPDATE
CASCADE. At that point it becomes more of a practicality versus
purity discussion: on update cascade keys are marginally less portable
and, unless used CAREFULLY and documented well, can lead to updates
taking an unexpectedly long time and to hard-to-comprehend database
schemas.
Don't go confusing things with your facts and logic.
-
RE: I don't wanna create a WTF.. database question
I've found a number of times that it bites me when I don't create an id key. The fundamental problem with using unique data in the table as the primary key is that any useful or "real" data in the table is subject to change, including the primary key. Change the primary key, and now any other tables which reference that key also need to be updated.
e.g. Let's create a table of users. The obvious primary key is the username. So other tables reference that key to show ownership/authorship/whatever. But Suzie Random (srandom) gets married, becoming Suzie Random Hacker, and wants to change her username (to srhacker). It's possible, but it's a hassle, because tons of things point to her username as a foreign key. If they pointed, instead, to an id which has no meaning outside the database, then nothing would need to change except the one entry in the user table.
I think using meaningful data as a primary key can typically be viewed as data replication. I almost always create id keys. It just normally makes things simpler. Worrying about the efficiency of joins/etc during design falls under premature optimization, generally (but possibly not always). Of course, I always make the "logical" primary key (username in this case) unique. -
RE: I don't wanna create a WTF.. database question
@Goplat said:
In schema 2 you could avoid the problem of having no numbers between n
and n+1 by using strings instead. You can always find a string that
sorts between two other strings, e.g. if you want an index between A
and B, use AM (M is the middle letter of the alphabet).
Um. Insert between A and AA?
-
RE: I don't wanna create a WTF.. database question
Schema 2 is better than schema 1. At least #2 allows you to retrieve a sorted list from the database, rather than manually jumping around the list following "next" pointers.
With schema 2, swaps are simple, just two updates. You could actually use swaps for all inserts, removals, and moves, bubble-sort style, but it would be rather inefficient. A better option for inserts would be to move all the affected rows first, and then insert. Then it's still just two updates (though obviously more than two rows may be affected). e.g. "UPDATE table SET index=index+1 WHERE index > $insertpoint; INSERT INTO table ..." The same scheme would work in reverse for removals. The scheme also work for moves within the list. You'd just move all items within a specified range up (or down) by one, and then update the moving item to be in the now-open spot. You could actually do this to swap, too, rather than making swaps a special case.
I think skipping indices is just going to make your code more complex, because you're still going to have to build in the case where there's no room to insert.
If your DB supports transactions, use them. You really need this to be atomic. -
RE: In the world of bits...
Inlining basically only makes sense if the function is extremely small, or called only from one (or maybe two) places. In either of those cases, the compiler will probably do the job for you. Manually specifying such things is generally a waste of time when evidence to the contrary is lacking.
-
RE: Rational agrument against Hungarian notation?
@dhromed said:
I use HN when there can be doubt about a type.
Take the varname 'coordSet', seen at a place [i]other[/i] than its declaration.
Array?
Map?
String?
'arrCoordSet', of course!
That seems to indicate that you don't know the code very well. I can go through my code and I know what types the variables are. Whenever I need to change/read someone else's code, I read it first, to learn what the variable types are.
Maybe Hungarian notation really does have some use (I don't think so), but you're making it sound like an excuse to not learn the code, which in turn means you wouldn't be safe modifying the code.
-
RE: Rich#$%^#$textfields
Well, if you're using Word, there'll be a little option (tiny drop-down box will appear at the end of the inserted text) when you paste to keep only the source text, or to keep the formatting, too. Outside of Word, I think you're out of luck, unless the other app supports it, of course. I do the notepad thing, too. If it's one line, I'll paste into the run dialog and recopy. It's obnoxious, but I'm not sure of a better way to do it. Consistent app support to provide pasted-text formatting options would be nice, but it's just not there.
-
RE: Overheard in the next cube
There is no default constructor for Boolean, so it's a compiler error.
-
RE: Does Agile work for standard software development
@Alex Papadimoulis said:
I have yet to see is a business workflow ("requirements") that cannot be known before development of the software and, therefore, question whether or not such a workflow exists. I've worked with clients who were simultaneously building their offices (physically) and developing their supporting software, but they knew what they wanted ("a system to manage real estate") long before they laid the first brick. It's simply a matter of understanding what they wanted; the approach that agile seems to take is "assume now, code it now, fix it later." And it is precisely this approach that I argue leads to maintenance problems down the line.
I think part of the problem with traditional methods is that they assume that the "requirements" are complete. "A system to manage real estate" is pretty vague. But lets say you hammer it down and force the client to attempt to define exactly what he wants. What's the likelihood that you'll really get everything the client needs? He'll forget something, or explain it poorly (so that you don't understand it, but possibly think you do). He'll decide he needs something else added thats "vital" but wasn't vital a week ago when he signed off on the requirements. And what happens if you put together exactly what he asked for and deliver it, and it isn't what he really needed? If instead, you constantly had feedback from him, you'd catch misunderstandings and missing features much sooner. That's part of agile methods. Rather than assuming that you can really get everything the client needs up front, you get it from him incrementally, and it works fine, because the implementation and design is also incremental.
To be honest, I think traditional methods are more likely to fall prey to assumptions than agile methods. With agile methods, you're constantly asking, "is this right?" With traditional methods, you're looking at the requirements and (potentially) saying, "this seems wrong, but it's what's on the paper."@Alex Papadimoulis said:
I have heard that this is mitigated through refactoring, but I just can't see how that could work. Whenever code is changed, test cases need to be run for modules that are directly and indirectly impacted. This results in a lots and lots of testing which gets to be pretty expensive; not only do you have to pay the tester for her time, but now she can't do her regular job, and her team's workload suffers.
You're mixing requirements and design too much. If a chunk of code is refactored, the requirements that code fills haven't been changed, only the way in which the the requirements are implemented has been changed. Automated tests can be used to make sure that the changed modules still exhibit the same behavior. If the behavior is still correct, why would the requirements suddenly be unfulfilled?
@Alex Papadimoulis said:
Bugs in information systems are often not programmer errors, but requirement errors instead. Unless AI has significantly advanced to the point of replacing human testers, I don't see how it would be possible to unit test non-obvious requirement errors.
I'm sorry, but it sounds like your saying that testers are supposed to refine the requirements. That doesn't seem to be the testers' job at all, and attempting to allow testers to refine requirements would invite lots of assumptions, something you accuse agile methods of. Requirements need to be refined by the client, which is, again, why agile methods stress constant interaction with the client. Iterative cycles allow the client to clarify any requirement errors, rather than assuming that testers can somehow divine the correct bahavior.
@Alex Papadimoulis said:
Actually, I'm hoping you could elaborate on how agile is more transparent. I think that this lies more in the competence of the PM than anything else. How does agile help in this? The main issue I have with agile as far as PM is concerned is that lack of accountability; some books I've read take the approach that no one is to blame for a problem but the process. That's all warm and fuzzy, but in the end someone needs to be "billed" for all the time fixing the problem.
I think the transparency he's referring to comes from the constant expose to the client. If the client comes in every two weeks or every month to see the latest interation's results, and sees nothing new, he knows something's wrong (and so does the PM and everyone on the team). With traditional methods, it's a lot easier to say, "It's going great!" and keep problems in the dark. This applies to both the client and the PM (hello Paula?). It's not impossible to keep things in the open with traditional methodologies, but it can be harder. Agile methods should make it easier to expose problems earlier.
-
RE: Does Agile work for standard software development
@Alex Papadimoulis said:
... take everything to the left of +1 SD, and you now have an overwhelming majority.
That's just ridiculous. Take everything to the right of -1 SD and you also have an overwhelming majority. Assuming a symmetric bell curve, the number of things which are better than average is exactly equal to the number of things that are worse than average.
@Alex Papadimoulis said:If they can't, then they aren't "good". "Good" is not how much C++ you know, but how well you develop software. A good team will naturally have experience and know what works (requirements, testing, etc) and what doesn't (just blinding hacking away).
You're right. Bad programmers are those who produce bad code. No matter the methodology, you will not get good code from bad programmers. So why choose a methodology based on getting the best from the worst? Isn't it more productive to get the best from the best?
You also seem to throw some serious straw-man attacks at agile methods whenever you speak against them. If you think agile methods are "just blindly hacking away", then I'd say you don't know what agile methods are.@Alex Papadimoulis said:
I've discussed this in a number of previous posts, but the key problem with these methods is that change is an expectation, not an exception. This leads to having your initial design documents (for the less liberal agiles that actually allow documentation) being inaccurate to the point of uselessness.
One of the fundamental ideas behind agile methods is that change will happen. You said it yourself. "It's unreasonable to require that no variation from the original specifications are permitted post-analysis." Doesn't it make more sense to expect change than to pretend that it won't happen and then force it to have a huge cost? Change will happen. It only makes sense to reduce the cost.
I'm also forced to wonder how the big-design-up-front fixes the documentation issue. If, as you say, change will happen, isn't the design document already doomed? The only way the design document can be guaranteed correctness is if it's actively updated throughout the coding process (to incorporate those inevitable changes). In that case, I fail to see how the methodology is really even relevant (with respect to the design document). It seems to me that if you want a design document, it'd be better done after the design and implementation is complete, to document the final state of the product, rather than the initial (and now inevitably incorrect) vision.
@Alex Papadimoulis said:
Poor design docs lead to a situation where coders have to reverse engineer the system in order to maintain it. This is bad news for the system and leads to a painful code decay (and absurd maintenance costs). This is just one of the many reasons that the "traditional" methodologies mandate strong documentation before developing and a "painful" change control process that involves updating the documentation.
I fully agree that poor design docs are bad news. That's why producing a huge document up-front seems counterintuitive. If it's bound to need change, and it's extremely painful to change it, isn't it harming more than hindering? I can see the value of planning, and in fact, would be afraid of any methodology that espoused no planning (agile methods do espouse planning, just not huge up-front design). However, investing large amounts of resources into a document which will be either 1) doomed to incorrectness or 2) expensive and painful to maintain seems like the wrong approach.
-
RE: Win32 C - append Url to path
Or someone using/writing a site mirroring program.
-
RE: Game engine WTF.
@Hux said:
Is this in reference to the dAB variable naming? In all honesty, I thought the 'd' in this case was referring to distance, perhaps, rather than double.
There's another strike against hungarian notation. Can easily be misleading, rather than informational.
-
RE: Win32 C - append Url to path
I'm all for using available functionality, but sometimes, the search isn't worth it. If I can't find it in a reasonable amount of time, and no one else can, either, then I'll just roll my own solution. Since what you need is just a loop to replace one character with another, I'd just write it and be done with it.
-
RE: OMG Injection attack
Yeah, not a WTF. There's no risk here that I can see. It just pushes MIME types. It could be a WTF if it was exposing files that should be hidden, but it's not allowing access above the pageroot, and I'm guessing there are no sensitive pages on the website. I am confused about the "this is normally a password-protected page" comment. Looks like there might be something wrong there . . .
Interestingly, if I go to "http://philip.greenspun.com/doc/sql/display-sql?url=/" (or give it any other directory), it churns for quite a while before I get a blank page back. I'm curious if it's going crazy on the server (looping or some such), or if it's just dropped me and neglecting to close the connection. If the script is hammering on the server when it gets invalid input, then it is a WTF. -
RE: Overheard in the next cube
"Null is not a boolean value, any more than null is a string value." <- Agh. I deleted that line. Sorry for the repitition. Looks like the forum software bit me.
-
RE: Overheard in the next cube
This has come up before here, and I still don't understand the confusion. A boolean value can be true or false. That's all.
If it's a Boolean (in Java), then it can be true or false. The reference to the Boolean might be null, but in that case, it's not a valid reference to a Boolean.
If it's SQL, a boolean still only has two values, true or false. Null is not a boolean value, any more than null is a string value. A null indicates the complete lack of a value. It's unknown/missing/whatever. Null is not a boolean value, anymore than it's an integer value.
The PostgreSQL documentation agrees with this:
boolean can have one of only two states: "true" or "false". A third state, "unknown", is represented by the <acronym style="font-style: italic;" class="ACRONYM">SQL</acronym> null value.