9,146 reputation
12340
bio website
location Melbourne, Australia
age 44
visits member for 3 years, 2 months
seen Oct 27 at 1:25

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! ;-)

about.me
LinkedIn


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...
Jun
6
comment Is BDD actually writable by non-programmers?
@MattiSG FWIW, using a DSL and BDD is the system I myself use. Requirements are defined as Entity-Feature-Benefit statements, and followed up with a spec which extend initial requirements statements using AAA (I.e: Given-When-Then) statements... essentially scenario statements. The difficulty when attempting to decode free text is that without a DSL, you don't have an easy means to define an algorithm that can generate meaningful collection scenarios. My point was that using the tests as a starting point to generate scenarios is kind of backwards.
Jun
6
comment Is BDD actually writable by non-programmers?
@MattiSG ...whether enforcing language constraints is worth anything. This is a good question. Free-form descriptions are more expressive and natural to the writer, but result in rambling commentary that requires dissection in order to derive a useful spec. By defining formal 'rules' (aka a DSL) for writing requirements and specs, you have a common language that both customer and programmer can understand, limiting misunderstanding. If you get the descriptions right, they can be used verbatim as a template for your tests. Thus no need for complex tools to "generate" anything.
Jun
6
revised Is BDD actually writable by non-programmers?
some formatting, and modified a sentence I didn't like
Jun
5
comment Is unit testing development or testing?
I was about to write a similar answer. While unit testing should be in the domain of the software developer, giving the testing team a sense of the code coverage can help the testing team to understand and target specific areas that may require greater attention by the testers. It can also be a way to keep the developers on their game in terms of ensuring they account for as many edge cases as is cost effective to do so. This allows the testing team to not only validate the entirety of the system, but also to account for all of the stuff that might otherwise be seen as costly to test.
Jun
5
comment Is unit testing development or testing?
Excellent answer, however I don't agree that tests should be seen as an authoritative source of technical specifications. Tests should be a confirmation of specifications, but certainly not a replacement. That is not to say that I am advocating for a big up front spec either, but rather that I'm making the distinction that we apply tests to validate the things we know about the way in which a system should behave, rather than having the tests define the behaviour. A pedantic distinction perhaps, but important nonetheless.
Jun
5
answered Is BDD actually writable by non-programmers?
Jun
4
awarded  Nice Answer
Jun
2
answered Does a team of developers need a manager?
May
31
revised I can write code… but can't design well. Any suggestions?
Additional tags, and I feel that the edit improves the readability of the question somewhat.
May
31
awarded  Guru
May
31
comment Is there a viable alternative to the agile development methodology?
@Pierre303 Moderators have the trust of the community to authoritatively close questions if they feel it is warranted. Notice Yannis didn't delete however, allowing the community to correct if needed. I've joined 3 others and voted to reopen mainly because (sorry Yannis) I think that the reason for closing the question doesn't really match the question or answers as shown. Remember that the moderators are doing a difficult job, and spending their own time trying to manage this site for all of us. personally I think Yannis has been doing a great job so far :)
May
31
comment Is there a viable alternative to the agile development methodology?
@Ryathal I don't really see the connection you've made between the links you provided and this question. Perhaps you'd like to fire up a chat about this to discuss with those who are interested?
May
30
awarded  Guru
May
30
answered Is it acceptable that after reading a certain technology in a book, you put it in your resume as a skill?
May
29
awarded  Good Answer
May
29
awarded  Good Answer