Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Is "Continuous Implementation" the name of a software
development methodology? If so, what is it exactly?
Do you have experience using it?
Note that I know what continuous integration is, but not continuous implementation.
Background: today I learned (second hand) of a company that
uses "Continuous Implementation" in the context of their
software development. Is it formally defined or is it part
of some agile software development methodology?
The best I could find was this paper in the European Journal of
Information Systems:
Agility Through Scenario Development And Continuous Implementation
"... a business and IS/IT initiative at Volvo ...
development and implementation of an agile aftermarket
supply chain. ... to create a platform, Web services, and
a Web portal for selling spare parts over the Internet. "
Try searching for "Continuous Integration". It's a Good Thing(TM), in my opinion. "Continuous Implementation" would only be a good development methodology in the Dilbert universe. ;)
Edit:
The original question was simply asking what "continuous implementation" is. Since this site is StackOverflow, not EconomicsOverflow or PolymerEngineeringOverflow, the correct answer is "nothing."
The question was edited afterward to expand the scope, but that doesn't really change my answer.
All references of this term I can find in the realm of software development appear to be a mistake where the author is really meant continuous integration, a common agile technique.
The OP now referenced a a paper using the term in the context of use of the term in an "agile" supply-chain management implementation. Even so, despite the publication, the term has not entered common parlance in SCM, much less software development, and thus has no generally-accepted definition.
I think, the OP is referring to 'Continuous Implementation' only. It is not a commonly used term.
I didn't hear the term, but in the Agile or Scrum methodology, the implementations happen frequently than the traditional waterfall model (but obviously not continuously as in 'Continuous Implementation').
At the company I work, we follow Scrum methodology to deliver the new version every 6 months. Since ours is a product company offering Software-as-Service, the implementations are in our control. We eventually plan to have more frequent implementations. This is much different from the pre-Scrum days, when the new version comes typically every 2 years.
Continuous implementation is a term used in game theory. See here for example. I doubt that this is what you're after, but there you are anyway.
MIKE, an information systems management approach, also uses the term; see here. The Volvo reference in the OP may be referring to MIKE or something similar.
Richard is likely correct that you mean Continuous Integration, a practice whose primary element is frequent builds to ensure the incremental addition of working functionality to your software.
The seminal article on this practice is "Continuous Integration" by Martin Fowler (this is the original, there is a link at the top to an updated version).
Sounds like marketing people mismatched the terminology. Happens all the time.
Actually, I think that this new animal comes from a Lean background (which makes sense in the context of Volvo). Nothing formal though. In other words, it sounds Agile, it taste Agile but nobody knows exactly what it means and, for these reasons, I'm sure Volvo's C-level managers like it a lot :) This makes my bullshit detector ring very loudly actually.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
We are transitioning across to BDD. Currently using specflow and visual studio to run our automated tests via Jenkins and have over 1000 tests in Quality Centre written in a more traditional fashion of which, the regression tests will be converted to BDD in time.
I'm looking for a repository (similar to test plan in Quality Centre) to house all our test cases/feature files. It must be compatible with Specflow and Jira. What do people use as a manageable test case repository for their tests?
Cheers.
I'm not 100% sure I understand your issue, not being familiar with some of the tools you talk about, but when you have executable specifications your test cases are in the feature files which are stored in the code base. This is part of the point, that your test cases are the things that get executed, so they are always up to date.
What #Sam-Holder said is good; adding to that because I'm familiar with the issue and the tools you're talking about.
You're probably used to the idea that Quality Centre contains a bunch of test scripts, some of which pass and some of which don't (yet).
When you're doing BDD with automated scenarios, they pretty much always pass, all the time. Half the things that QC does simply aren't needed with modern Agile processes.
A pretty common practice is to put the scenarios into the Jira story until they're automated. They're transient. Nobody ever looks at Jira once the story's done. The codebase is the single repository of truth, and anything that lives in Jira gets ignored.
The automated scenarios are checked into the same codebase as the code. If the scenarios go red (fail), the team makes them green ASAP. They provide living documentation for the code. See if you can find someone to show you what Jenkins looks like in action and you'll get a better picture. Commonly the Jira number is added to the check-in comment to provide some level of traceability.
I think it's good practice to keep any manual test cases checked in alongside the automated ones (though please do question why they're not automated; if you automated them in QC you can usually do it with SpecFlow). This helps the test cases (scenarios) to provide living documentation for the code. In fact, getting rid of the word "test" was part of the reason why BDD came about, because BDD's really about analysis and exploration through conversation. It provides tests as a nice by-product.
To answer the question, the most commonly used tool at the moment is Git (at least for newcomers). It's version control that the devs are using. SVN / Mercurial are also OK flavours of version control. Get the devs to help you.
If you're still working in a silo and not talking to the devs, don't use BDD tools like SpecFlow - you'll find them harder to keep up-to-date, because your steps will probably be too detailed and English is trickier to refactor than code.
Better still, use the BDD tools and go talk to the devs and the BAs / SMEs / Product Owner who understands the problem. Get them to help you write the scenarios. When you start having the conversations, even over legacy code, you'll start understanding why BDD works.
Here's a blog post I wrote on using BDD with legacy systems that might also be helpful to you. Here's a blog post on the BDD lifecycle: exploration, specification and test by example. And here's one to get you started on how to derive that "Given, When, Then" syntax using real conversations.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Do you find that corporate buzzwords or heavy management jargon gets in the way of software project communication? for example using words such as
Mainstreaming
Holistic
Contestability
Synergies
etc.
Would you rather see a initiative within the industry to put a stop to jargon such as this to help people communicate better and keep project communication in plain English? Is it even a problem? What are your thoughts/anecdotes?
I actually like buzzwords, when they are used in moderation.
They became buzzwords for a practical reason: Even though the concepts may be very complex and/or abstract, there is a consensus on the meaning. So with only one word, you can convey a whole lot of information to a large group of people. I see it as a form of encapsulation of information.
(Notice the use of the slightly outdated buzzword encapsulation?)
Of course, that is exactly the reason why many people start to abuse them: They only convey the general concept (i.e. why it's great to do FizzBuzz), and avoid discussing the messy details (i.e. why it won't work).
And since using a buzzword gives the impression that you are deeply familiar with the subject at hand, it can be used to silence others in the discussion.
Conclusion:
Buzzwords are ok - if they are used in the right way. If you want to improve your team communication, train them in the proper use of buzzwords.
I think some kind of industry-wide initiative would be impractical as jargon is in the eye of the beholder.
I think all you can do is make sure that you don't use buzzwords yourself even when communicating with people who do. For example, use the word "people" when talking to a Project Manager who refers to you and your colleagues as "resources".
The use of technical language can both help and hinder project team's progress, depending on appropriateness.
First it's necessary to point out that what is considered "too technical" depends purely on perspective. "Mainstreaming" is as much of a technical term, as SSD, CORBA and SOAP. Something that sounds as jargon nonsense to one person is actually a shortcut to communicate a complex concept for another.
Software development as a rule is cross-domain activity involving in addition to the software knowledge one or more technical user domains. It is a big mistake to assume that sales, marketing, management and banking (just to name a few fields often incorrectly considered "non-technical") haven’t developed and advanced their own complex body of knowledge, in other word — technology: sales technology, marketing technology, management technology and banking technology.
And it’s project manager’s responsibility to facilitate productive communication between representatives of different technical domains. Some suggestions:
Make handy a project dictionary that can be accessed and updated by everyone involved.
Ensure that common denominator language used for cross-domain documentation (i.e. functional specs).
Introduce domain specific terms only when necessary, but then always provide a brief explanation of the meaning (don’t “build from scratch” —leverage the wealth of online encyclopaedias by linking where possible).
Make sure that there is common understanding amongst the project team of the key terms.
Remember that what is considered “technical” depends purely on perspective and you need to facilitate communication in all directions, not just one-way (which is often from software developers to business users).
At the end the software will have to work in the realm of users and you have to make a judgement on how much the UI will rely on specific domain language (this is going to be a trade off between easiness-to-learn and usage-efficiency).
Technical jargon (ORM, TDD etc.) makes one's speech more precise. Corporate buzzwords (aka management jargon), on the other hand, are designed to be able to express vague ideas when full information is not available.
As such, management jargon serves its purpose pretty well, in the sense that it does allow managers to effectively communicate about thins they have very limited understanding of. That said, good manager knows when NOT use the jargon, such as when talking with developers, or with executives, both of whom hate bullshit.
Based on the above, the (Anti-)Buzzword Movement, should rather increase awareness of the proper usage and application of management jargon, and encourage proper information encapsulation only with appropriate auditory.
Personally, I think that the jargon should be used more. I see this occurring more and more and IT people want to simply hide behind the technical elements of the world and act like it is completely the business folks responsibility to speak more geeky.
I'll be honest, speaking more GEEK is not something that the business people can do and you should not want that to occur. Learn the jargon. Become one with the jargon. Own the jargon. Then the next time you are discussing things, you'll not be back pedaling.
Take ownership of the business terms and apply them to the technical side of things...
What's wrong with "holistic" or "synergy"? These are normal plain English words.
Every field has it's own jargon, and that must tell us something - people like having special words, phrases or assigning special meanings to existing words that are only relevant within their own field. I suspect if we went back to the pyramids, there'd be a full set of architectural and building phrases that your average Egyptian just wouldn't understand. So banning jargon just wont work, creating an FAQ and glossary normally do the trick.
BTW This must be a case of pots and kettles. Does anyone outside IT think phrases like - "...We'll use an ORM, and then WCF will talk over HTTPS, throw in a bit of AJAX and some clever CSS on the client and we're laughing ..."
Absolutely. Since managers only talk in general, and we as developers want to understand the precise meaning. I personally fall asleep trying to read abstract writing filled with buzzwords.
The worst being SOA. Neither academic folks nor managers understand it though both use it extensively.
I can't stand buzzwords. One person's "encapsulation" is another's Orwellian destruction of language. Buzwords appeal to the same people who like "decks" rather than memos. For something to act as a representation of many possible things [e.g. "leveraging resources" can mean pretty well anything from using double-sided printing options to drafting people for the Army] there is necessarily going to be a dilution of meaning. If a senior lawyer in my firm were to ask me to "leverage the resources, then run it up the flagpole to get the ducks in line", I'd know that he was tossing back the Johnny Walker at lunch.
Conversely, if I were to respond to a senior partner's memo request with emtpy catch phrases such as those above, I'd be fired on the spot for being an idiot - and rightly so. Too bad the rest of the white collar world isn't like that.
Grouchy Old-fashioned Gen X'r
I'm OK with buzzwords so long as all the stakeholders (see what I did there?) are clear on the shared meaning of each word/phrase.
In general I think that buzzwords are good when used for encapsulating ideas and concepts. it simplifies communication between people who understand the words. However, I draw the line when people use a buzzword when a perfectly normal word would do. I know someone that will say they were "On an Audio" when they mean phone calls or say "dialogging" instead of talking. It makes me want to hit them. Hard!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have found a software development system which is currently free to use and develop with.
This system is completely codeless and one can develop business oriented applications effortlessly using its GUI and a bit of MDA. The site is : http://www.codeless.com/
But unfortunately it is in Dutch language.
I would like to know if anyone has ever used this product ?
How efficient is this approach and product?
Can one develop codeless applications?
I have looked at the site but the story is extremely vague.
For majority of non-Dutch speakers, I have translated the following text:
Klaar voor de toekomst!
Stel dat u over 20 jaar nog steeds
dezelfde software zou kunnen gebruiken
als nu. Toekomstmuziek? Nou, welkom in
uw toekomst dan. Want Codeless
Technology ontwikkelt software zonder
code die simpelweg niet veroudert.
Door ´reverse enginering´ kunnen wij u
laten zien hoe uw software-pakket er
in Codeless uit komt te zien. En door
gebruik te maken van interfaces,
kunnen we bepaalde delen van uw
systeem vervangen zonder dat er een
Big Bang implementatie noodzakelijk
is.
Wij hebben een manier gevonden om onze
software voor altijd mee te laten
gaan. Omdat we het simpelweg zonde van
uw tijd vinden om telkens opnieuw uw
bedrijfsprocessen te moeten uitleggen
aan een nieuwe ICT-leverancier.
Uw systeem is perfect aangesloten op
uw bedrijfsprocessen. En dat terwijl u
de nieuwste technologieën snel en
voordelig in kunt zetten om zo
concurrentievoordeel te behalen.
Natuurlijk moet u updaten. Maar met de
software die u nu door ons laat
bouwen, bent u gegarandeerd klaar voor
de toekomst!
That translates to:
Ready for the future!
Imagine you are using the same
software in 20 years. Impossible? No,
welcome to your future. Because
Codeless Technology creates software
without code that does not age.
By 'reverse enginering' we show you
your software in Codeless. By using
interfaces, we can replace certain
pieces of your system without the need
for a Big Bang implementation.
We have found a way to let our
software last for ever because we
think it is a waste of your time to
explain your business processes to
your ICT supplier again and again.
Your system is perfectly connected to
your business processes. And still you
are able to use the newest
technologies quick and easy so you
have an advantage on your competitors.
Of course, you still have the need for
updates. But with our software, you
are guaranteed future ready.
It looks like they have developed a product that uses an existing system and creates a new one using the old system as guide. Without the need to write code. This looks great, but I have serious doubts.
My first question: if they are so excellent, why is their site not in English?
I'm not familiar with this specific product, but I have some familiarity with the "theory" (such as it is) of codeless development.
The primitives of programming languages are there for a reason. So there is a tendency for "codeless" or "mouse-based" development systems to gradually accumulate features that correspond to the primitives of programming languages: something similar to function calls (for reuse of pieces of a design), references to parameters within functions, things that loop, conditional branching, things that aggregate several actions into a single action, things that do arithmetic or string operations, etc. By which point they end up with the same issues as all development systems, which all derive from the tendency of users to push the envelope in looking for ever more complex problems to solve. So then they need refactoring and other nice IDE-style features to help them manage the complexity - by which time the "codeless" distinction is more to do with marketing than actual user experience.
We even see this tendency in many attempts to "start again" with a new set of primitives in a text-source programming language. Haskell does not truly eliminate procedural, stateful coding. It has a way of mimicking such capabilities that tastes pretty authentic - because if it didn't, users would try to simulate it themselves and get it wrong.
I've done some reading on their site.
It seems to me that they build software for you, which they claim you can expand effortlessly. I don't see that they claim you can use their software te build your own software without using code. Their concept in their words:
Maatwerksoftware, die nooit veroudert, die u zelf kunt onderhouden én uitbreiden en die bovendien wordt gemaakt waar u bij staat.
That is:
Software built to your requirements, that never ages, that you can maintain yourself, and that on top of that is made while you're watching.
I conclude that they build it, not you.
I've used the visual development tool of the C Control microcontroller. Although it was possible to use almost every feature of the underlying language (BASIC) it found it to be a waste of time. "Mouse coding" simple loops took way longer than just writing the plain BASIC code.
During my first steps into coding and development I tried other products, (mostly game creators) but they always either lack the features normally available in a coded language or are very slow to work with.
But during the last years I noticed an increase of people who are no longer willing to read (natural) text which they cannot understand the first time they read it. Just a single subordinate clause and they don't want to continue.
So I guess there is a market for these kind of codeless development tools, since you can easily get results and the learning curve is much lower. Most tools I used where pretty self-explanatory.
IMHO codeless development enviroments are best suited for
beginners
people who don't want to learn coding
This approach looks great, worth a consideration. Even though it's still at an experimental stage: http://subtextual.org/subtext2.html
The results of "codeless" or "graphical" systems that I've seen always end up not reducing real complexity, with the drawbacks of no collaborative effort, cant diff/patch, can't do a version compare, difficult to put in source control, etc.
In short, just not a well thought-out.
I'll bet that they don't scale well to large data sets either.
I have tested version 1 current version is 2. but as there is not documentation available in English I am a bit baffled as to how we can go ahead building our apps as per our requirements.
The samples provided looked impressive though.
Just my two cents, the idea behind codeless development is not only for beginners/people who don't want to learn coding, but also can be used to teach younger children programming, and utilize it as a storytelling medium.
I am,of course,referring to Alice.
It has it's market, but I don't forsee it taking over traditional programming (eg. typing on the keyboard) due to it's clunkiness.
The appropriate stance with these sort of products is extreme scepticism. I distinctly remember this...
The Last One
Which was a product, released in 1981(!) which claimed to make programmers redundant by generating commercial applications codelessly.
That said, I am currently using a codeless development environment - Wirefusion - for generating 3D interactive java applets. It's extremely good, but it's targeted at a very well defined domain and even there has some issues.
There was Borland's ObectVision in the late '80s.
You can download a copy from an abandonware site.
Something like Scratch or Lego MindStorms is what comes to mind when thinking about codeless software. But this seems like helping someone to code instead of being 100% codeless. And I think that is the way it will have to work in order not to be so limiting. Over time, like all languages/APIs it will improve and more and more people will come out with their own buckets of coding blocks to make it more versatile. No matter what happens though I would always like a way to tweak all generated code, much like a WYSIWYG HTML editor. It will be difficult at first but will only get better with time. But no matter what, coding by hand will always reign supreme.
Replying to the post of geocar..(cant reply anymore to my own post)
To say what the differences are with other I4GL is hard since i dont know all the tools out there, but let me put it this way. If one compares Codeless to MS CRM 4.0 and Microsoft M, what would you think are the differences with I4GL tools?
The proof is in the pudding; I don’t understand why this Bernard deleted who we are. If Charles Simonyi the Billionaire ex-Microsoft guru who has been trying to do the same for 15 years would comment here, would he be deleted?
David Roth, Chief Visionary, Simparel, Inc.
David.Roth at Simparel dot com.
My boss has a good way to generate apps without his having to write code. He has an automatic programmer (me) write it for him. He uses domain-specific language, and gets a working app. Anything that does the same job would have to be about as smart (or dumb) as that.
When requirements are communicated, a language of symbols is used, whether it is keyboard clicks, mouse clicks, or any other form of input.
If a language maps well onto user concepts and allows very little room for misinterpretation or inconsistencies, then it is a good domain-specific-language.
It is good to try to find better domain-specific-languages.It is bad to try to sell one if you don't have one.
So I guess there is a market for these
kind of codeless development tools,
since you can easily get results and
the learning curve is much lower. Most
tools I used where pretty
self-explanatory.
IMHO codeless development enviroments
are best suited for
beginners people who don't want to
learn coding
That is exactly true - and what is accomplished by the neatComponents codeless development platform.
Have a look at www.clearString.com which is targeted at those users
David
Encanvas is completely codeless. It was originally created back in the day to author enterprise-grade situational applications but in the last decade has been used to build anything from spreadsheet replacement type apps to regional traffic systems, business intelligence platforms and eLearning applications.
encanvas doesn't come cheap. It's engineered to enable IT teams to move away from coding and comes with all of the tools you'd expect including cloud deployment.
encanvas is built on .net.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
In pair programming, the experience of every member of the team can be spread to new member. This experience is always in sync with the code, because the "senior" of the pair knows how the code works and what the design is.
So what is the utility of design documentation in this case ?
UPDATE
I don't imply no design, I imply no documentation.
With a team which practice pair programming I think that everybody is disposable, because everybody knows the code. If the senior developer leaves, I think that there is always at least one person who knows the code, because the experience was shared before.
What if your team is larger than 2 persons?
Just because two people know a part of a system does not mean it shouldn't be documented.
And I would be glad to know that I don't have to remember every tiny detail of a system just because it it's stored nowhere else than in my head.
For a small system this might work, but as the system gets larger, your limiting yourself and your colleagues. I'd rather use the memory capacity for a new system than to remember everything of the old system.
Have you ever played "telephone?" I don't think you should play it with your codebase.
What if the senior programmer leaves the company/project?
The set of deliverables should be decided independently of whether you use pair programming or not.
Six months or two years later, all the people involved could be in a different project (or a different company). Do you want to be able to come back and use the design documentation? Then, produce it. If you don't want to come back, or the design is simple enough that with the specs and the code you can understand it without the aid of an explicit design document, then you may skip it.
But don't rely on the two people explaining the design to you one year later.
Maintenance. You can't expect the team to remain static, for there to be no new members or loss of old members. Design documentation ensures that those who are new to the project, that have to maintain it years down the line, have information on decisions that were taken, why the approach was chosen, and how it was to be implemented. It's very important for the long term success of a project to have this documentation, which can be provided via a combination of traditional documents, source comments, unit tests, and various other methods.
I don't see that pair programming makes design documentation obsolete. I immediately have to think about the Truck factor. Sure, the senior may know what the design is. But what happens when he is ill? What happens when he gets hit by a truck? What if he is fired?
Pair programming does spread knowledge, but it never hurts to document that knowledge.
Who knows about the first-written code? The answer is nobody knows, because it hasn't been written. The reason it hasn't been written is because nobody knows what to do, hence the need for a design document.
Pair programming is just two people sharing one computer. By itself, it says nothing about what kind of design methodology the pair(s) uses.
Pair programming, when taking as part of "Extreme Programming", means following the Extreme Programming guidelines for design. This typically involves gathering and coding to "user stories". These stories would then stand in place of other design documentation.
The experience of people may be in sync with the code, as you say. But the design decisions are not all captured in the code - only the choices made are there.
In my experience, to really understand why code is designed the way it is, you need to know about the design choices that were not selected, the approaches that had tried and failed etc. You can hope that the "chinese whispers" chain transmits that correctly, given that there's no record of this in the code to refresh memories or correct errors...
... or you can write some documentation on the design and how it was arrived at. That way, you avoid being taken down a dark alley by the maintenance programmers in future.
Depends what you mean by "design documentation".
If you have functional tests - especially behaviour-driven development (BDD) tests, or Fitnesse or FIT tests then they're certainly a form of "active documentation"... and they certainly have value as well as being regression tests.
If you write user stories and break them down into tasks and write those tasks on cards for pairs to do then you're doing a form of documentation...
Those are the two main forms of documentation I've used in XP teams that pair on all production code.
The only other document that I find quite handy is a half-page or so set of bullet points showing people how to set up the build environment for a development machine. You're supposed to maintain the list as you go along using it.
The code base may be so large you can't humanly remember every detail of what you were intending to implement. A reference is useful in this case.
Also, you need a design if you are interacting with other components etc.
Well if you want a spreadsheet program instead of a word processor a design doc use useful :-)
XP, pair programing, agile, etc... do not mean you do not have a plan, it is just a far less detailed plan (at the micro level) of what is going on. The use cases that the user picks are more of the design, and it is more of a living document than with other styles of design/programming.
Do not fall into the trap that because youa re doing something "cool" that you no longer need good practices - indeed this style of programming requires more discipline rather than less to be successful.
Pair programming is an opportunity for the team to avoid having to spend a large proportion of the project time on documenting everything. But the need for documentation depends on how good you are at remembering the important stuff and how good your code is. You may still want lots of documentation if the code is difficult to work with.
You could try some experiments:-
Document a couple of small parts of
the design and note how often you
have to refer to it.
Document stuff that is always a pain
to work with.
No Nor does lack of pair programming mean you need documentation. Documentation is needed! What it looks like may surprise you!
An agile team will decide when and what documentation is needed. A good rule of thumb, if no one is going to read it, don't write it. Don't get caught up in the waterfall artifact thinking by provide artifacts because the Project Manager says so.
Most think of documentation as something you do with Word. If an agile team is working properly, the code itself, with TDD (test driven development) will have a set of automated test that document and enforce the requirements. Image, documentation that is in sync with the code ... and it stays that way.
Having said that, pairing does help domain, application, practice and skill knowledge propagate through the team very quickly. Pairing also helps ensure that the team follow the engineering practices including TDD and other automated test. The results are that the application remains healthy and future change is easy to bring about.
So, bottom line, pair programming produces better documentation. It does not eliminate documentation (although you might not be able to find a Word document).
I am a pro-advocate and a fan of documentation. Pair programming does not require "one senior developer". In my experience with pair programming, developers of all levels are paired together, for the purpose of rapid development. There are many times I worked with junior developers and would trade off on the keyboard. There are many times I worked with senior architects and would trade off on the keyboard. Documentation is still necessary, especially with your core components and database.
Pair Programming only enables your coding and logical aspect.
But documentation is good practice. Always do documentation...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
What software do you use when designing classes and their relationship, or just pen and paper?
I find pen and paper very useful, and I try to get as far away from a computer as possible. If I do it on the compy, I'm always too tempted to start programming the solution. That inevitably leads to me changing things later that I would have spotted in the planning phase had I actually spent a good measure of time on it.
I usually start with a empty interface then start writing tests. I then generate the members using refactoring tools. For me unit testing is part of the design.
OmniGraffle (Visio-esque app for Mac OS X), sometimes. Otherwise, just pen and paper will do.
It's easy, while in the paper-and-pen (or whatever non-code equivalent you prefer) stage, to overstay, falling prey to the dreaded YAGNI syndrome. How many of us have carefully designed in some "sexy" feature that ended up never being used? (Raises hand. Hands.)
Small iterative test-driven steps and frequent refactoring - let the code tell you what it wants to be.
Most of my projects start out with the only certainty being that we won't end up where we currently think we will. So spending very much time on Big Up-Front Design (or Big Design Up Front if you prefer) is wasteful - better to start with the first thing we want to do and see where we end up.
It kind of depends on where you consider design to end. I read an article a few years back that presented the idea that coding is design - or for the Big Process fans at least it's the back-end of design. It rang true to me and changed forever the way I viewed the stages of the development process. Of course, I've just googled like crazy for the darn thing. Could I find it? Could I heck. Perhaps I dreamed the article and it's all my own idea. Yeah, that'll be it.
Pen and paper for the first draft. Umlet to digitalize it. It's very minimal but it does what I need
I use pen and paper.
For all planning purposes, it's the fastest way.
I get lost in layout and finetuning when I use a UML package.
But that is my burden.. :-)
Go for PENCIL and paper, or a whiteboard. Anything permenant-marking like a pen and you'll have a pretty messy design!
Whiteboard for the first 35 or 40 drafts. UML is nice after that, but not particularly necessary. The best documentation after you've hashed out the details is clean code.
Mostly pen and paper, although I occasionally break out Visio and just do some rough diagrams.
Would be nice to have a fancy tool I guess, but it would just be another thing to learn.
When doing an initial design I like a whiteboard and 1 - 3 other developers to bounce ideas off of. That's usually enough to catch any glaring errors/fix any tricky situations that may arise without dropping the s/n ratio by too much.
I find pen and paper, a whiteboard and possibly some CRC cards to be very useful. Most of the time I think a whiteboard and some stickers or cards with the class and/or module names written on them work best when doing planning and designing as a group. Pen and paper is fine if you are doing the activity alone. Once you have the basic structure set you can always make a pretty UML diagram.
Pen and Paper and/or Whiteboards for drafting, a more comprehensive tool for documentation purposes.
I mainly use Class Diagrams and a few sketches with Sequence Diagrams to get most of the relationships right.
About the tools: At work I use Enterprise Architect but personally I find Visual Paradigm for UML a better choice. The latter is much more flexible and allows quick drafting as well.
At VP they also have a version called Agilian for some time now (which I have not yet used) which seems to be even more flexible, allowing sketches to become documentation in no-time... maybe one day this tool will replace my paper sketches (save the trees :P).