8,946 reputation
12038
bio website
location Melbourne, Australia
age 44
visits member for 2 years, 9 months
seen Feb 7 '13 at 13:27

By day, a mild-mannered software developer with a keen interest in those areas of computer science that deal with the psychology of human machine interaction, and how that affects the processes and principals which we apply to create useful software.

By night, I imagine I'm the coding rebel, defying all conventions and "sticking it" to "the man" while liberating the free-thinking and allegedly down-trodden cube rats that I resemble during the day!! Or, I have a vivid imagination and way too much time on my hands! ;-)

TechBlog
Blog
Opinion Blog
Twitter
about.me
LinkedIn


Feb
7
comment functional requirements - use wording based on verbs?
@PeteKirkham You've described a hardware issue. Specifically a specification of form, not of function. This does not invalidate my answer to the OP's question which is about functional specification. Addressing the case you have described however, your functional specification might be "Given 'Software Configuration X', When CPU usage exceeds (a pre-specified limitation & time), Then Expect System Failure". Better yet, replace "system failure" with a "recovery process" to specify how to avoid failure. Sometimes we need to think a little creatively in order to uncover specific behaviours. :-)
Nov
27
comment What should be allowed inside getters and setters?
To avoid having too many comments here, I'll take this conversation into this chat and address your comment there.
Nov
27
comment What should be allowed inside getters and setters?
I've created a Chat Session to allow these comments to continue as needed.
Nov
27
comment What should be allowed inside getters and setters?
@methodman Yes, I agree that a public field is wrong, however a public property can be useful. That property can be used to provide a place for validation or events related to the setting or returning of the data, depending on the specific requirement at the time. Getters and setters themselves aren't wrong per-se. How and when they are used or abused on the other hand can be seen as poor in terms of design and maintainability depending on the circumstances. :)
Nov
27
comment What should be allowed inside getters and setters?
I think you're missing the point of the article, which suggests using getters/setters sparingly and to avoid exposing class data unless necessary. This IMHO is a sensible design principle which should be applied deliberately by the developer. In terms of creating properties on a class, you could simply expose a variable, but this makes it harder to provide validation when the variable is set, or to draw the value from an alternate source when "got", essentially violating encapsulation, and potentially locking you into a difficult to maintain interface design.
Nov
26
comment What should be allowed inside getters and setters?
@glenatron You miss the point that I'm writing about. Side effects within properties aren't always predictable. When you set a property Value, you expect that same value to be returned. When you call a function that may use a value, then you assume the output won't necessarily be that value itself.
Nov
26
comment What should be allowed inside getters and setters?
@MarkByers You may wish to validate input of floating point values by applying a rule that only a fixed number of decimal places is allowed. In that circumstance, you could either raise an exception if too many decimal places are input, or you could simply round the input value. This may be preferable to raising an exception. I agree though that the sentence you've quoted probably needs to be modified. I'll think about this and edit. :)
Nov
25
comment What should be allowed inside getters and setters?
There are a couple of problems with this. Arbitrarily setting a value creates a deliberate and unclear side-effect. Also, it doesn't allow the calling code to receive feedback which could be used to better deal with illegal data. This is particularly important with values at the UI level. To be fair though, one exception I just thought of could be if allowing multiple date formats as an input, while storing the date in a standard date/time format. One could at a stretch argue that this particular "side effect" is a normalization of the data at validation, provided the input data is legal.
Jul
6
comment Is committing/checking in code everyday a good practice?
+1. I once worked in a team where we had to check code into the vcs every day, even if the code was a spike or a useless investigation. It proved inefficient and wasteful, particularly because it required periodic maintenance to clean the vcs up. It was a due to combination of paranoia over potentially risking losing a little time to redo something, and because the manager had read in a book that you should commit every day. An extreme example perhaps, but seriously, if you haven't the judgement to know whether it's "worth" checking something in, you're probably not well suited to the job.
Jun
25
comment Unit and Integration testing: How can it become a reflex
@superM LOL! I know what you mean. Overhanded political correctness gets my goat. I tend to write either entirely gender neutral, or use "he" exclusively simply because it's kind of natural to relate such references to your own gender. My comment was however intended to be more generally applied, and not specifically to call out any particular individuals. ;)
Jun
25
comment Unit and Integration testing: How can it become a reflex
Disappointing if plus and minus votes are being offered on whether the OP is using appropriate gender form. Surely the quality of the question is in what is being asked and its relevance to the site, and not on subjective views of whether the inclusion of both he's and she's are to be considered sexist or not. This kind of friendly bickering really won't help the reputation of the site... or those involved. (I'm just saying!)
Jun
25
comment What are the barriers to adopting best practice? How can they be overcome?
Reluctance often results in a certain laziness, which ultimately breeds ignorance.
Jun
25
comment How to deal with colleagues refuse to follow practices?
OP may wish to change the wording of the question title and content slightly, as the question appears on the surface to be situationally applicable to any workplace. E.g.: Is the question supposed to be asking for a ruling on which practice should be used, or about dealing with a frustrating colleague who seems to bend the rules? Otherwise, the question comes across as a little generalized and may likely be voted to close as either off topic, or not constructive.
Jun
14
comment Is BDD actually writable by non-programmers?
+1 Communication really is the key, and the scenarios really do need to be in the terms that the business people us, so in keeping with the OPs question, if we create a DSL, this really needs to be able to be a closer match to what the customer is going to say, and not what the programmers think the customer should be saying.
Jun
12
comment I can't program because the code I am using uses old coding styles. Is this normal to programmers?
@deadalnix First jobs rarely offer the opportunity to choose the people you work with. Often you won't know how much people really care about code quality until you've worked with them for a while. My answer helps the OP understand this. Your statement about an inability to unit test before refactoring is patently wrong. Trying to refactor before unit tests increases overall risk. Chasing bugs without tests is inefficient and exhausting. People who care about code quality focus heavily on tests and clean coding technique. I don't get your implied objection, happy to chat about this offline :-)
Jun
7
comment Is writing software in the absence of requirements a skill to possess or a situation I should avoid?
I understand where you're coming from, however what you suggest is usually an expensive approach. Obviously I'm not suggesting the prototype is a complete product, but anything you build where there is any interactivity will require time to develop. A less costly option is to stand at a whiteboard, sketch out a few ideas, and ask targeted questions to help you narrow down your criteria. I'm also not advocating for creating a large spec. Outline documents, or even test code templates, produced iteratively and as needed, are usually simpler and cheaper than prototyping first.
Jun
7
comment Is writing software in the absence of requirements a skill to possess or a situation I should avoid?
Hi Trent, while I agree with your comment in principle (and I'm also tired of seeing how people use Agile as an excuse to screw the development process and call it "being agile"), this answer doesn't really address the OP's question, which isn't about Agile, but is instead asking about whether writing software without requirements is a skill to develop. Perhaps you had intended to add this as a comment to someone else's answer?
Jun
7
comment Is writing software in the absence of requirements a skill to possess or a situation I should avoid?
Agile is not about intuition, it's about communication. Delivering working software often in order to receive feedback often is encouraging communication and valuing the delivery of the things the customer needs. Yes, experience comes into play, but you are more likely to develop what the customer needs if you first ask what the customer requires. The so called 80:20 rule doesn't really apply unless you are very familiar with the customer's business domain, and even then I'd take that 'statistic' with a large spoon of salt.
Jun
7
comment Is writing software in the absence of requirements a skill to possess or a situation I should avoid?
... however, specs shouldn't necessarily be written in stone. Prototyping (essentially spiking problems) are most valuable when they feed new information back into the spec and where the spec is permitted to change to accommodate the things you have learned from the prototype. Without the spec, you risk simply making things up as you go, which isn't always in the best interests of the client. Clients expect you to fulfill their needs, and you risk less friction when you can provide evidence that you have agreed to something, even if only tentatively.
Jun
7
comment Is writing software in the absence of requirements a skill to possess or a situation I should avoid?
+1 for the spec never being perfect, but -1 for the spec being unnatural and outdated. Think of requirements as a list of features a client wants, and a Spec being the list of behaviours that define what the customer needs. Essentially a contract of sorts defining how the system functions, instead of what the system is. Big up front design and specification is problematical, yet like all big problems is easier to do when broken down to be done a bit at a time. Prototyping is also rarely cost effective if you have no idea WHAT to prototype. This is where specs offer a starting point...