|
Who needs specs in an agile environment?
Let's just start with 'int main(int argc, char **argv)' and take it from there as we learn what is needed. We can code it immediately, and the code will show how to solve the problem. Code will never be out of sync with the spec, because the code is the spec.
As long as you use reasonable variable and function names, you don't even need comments. Out-of-date comments are even more misleading than out-of-date specs, because you trust them much more, being so close to the code. We all know that documentation is unreliable and should never be trusted.
The only thing that matters is what is written down as code. The code is the terrain. Design, specs, comments or any other sort of writing are just poor maps of the terrain. Get yourself out in the terrain to see what it is really like. Be agile!
|
|
|
|
|
I thought you were joking for a moment.
OK, when you grow up and write some real software you will know what I mean.
|
|
|
|
|
I did my first programnming assignments at the University on 80 column punch cards.
|
|
|
|
|
SO if you have been in the game so long why havent you ever had to work with a big complex spec, something like USB for example, or the GSM spec?
|
|
|
|
|
I am very happy with good specs; I have read thousands of pages of ISO and ITU standards, some of which are excellently written. Especially for interface/protocol specs, I am very fond of specs based on state machines - they tend to make the spec terse, complete and unambiguous. (If you would like an example, pick up X.225, the OSI protocol stack Session layer - it is outdated now, but could serve as schoolbook example of a FSM based protocol spec.)
If you are still in doubt: In my first post in this thread, I was most certainly joking. Except that I think it is no laughing matter, it is rather sad how little the young crop of "agile" developers value specs, good designs and thorough problem analysis. It most certainly reduces the quality of the software we produce nowadays.
If you want well designed, robust software today, do not try to find it among those agile software broilers pouring out from the universities. Seach for those who know the problem domain. If you want a sound editor, search for studio people. Do you need document creation software, go to the publisihng business. Do you need software to keep track of your dog breeding, go to the farmers' organizations. Do you need a programmer's workbench, go to the open source community, that they know well and produce high quality software for. But not for movie editing, dog breeding, office automation or map construction.
For many youngsters today, agile makes you specless. You are free to take whatever next step you want, without asking anybody without telling anybody.
Agile doesn't have to be that way. But quite often, that's the way it turns out. Writing down anything else than code is something your boss forces you to (if he does!), and you do it after completing the code; you do not preapre and use it as an aid in the implementation phase. If you suggest anything in that direction, everybody under thirty (and a fair share of the older ones) give you that ugly look and snare "Waterfall!" at you.
|
|
|
|
|
Sarcasm never comes over well in text. 
|
|
|
|
|
In this scenario agility is a must, and a good endurance helps a lot, to run away from angry customers 
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Specifications?
Wait, are you from the land of fairies and unicorns where such a thing as specifications exists? 
My current specs are "this is sort of what we want, can you do that?"
"Sure", and then I just make something and hope for the best
Mostly, I steer the customer instead of the other way around.
|
|
|
|
|
Those are called 'requirements' normally and yes, I have worked with blank sheets of paper too.
I am talking about stuff like the USB spec.
|
|
|
|
|
The kind that describes how to use a third party system? 
Those seem to be imaginary even in the land of fairy tales 
|
|
|
|
|
|
Munchies_Matt wrote: And have you ever looked at code, or products that supposedly implement the spec, ...and just the basics of the spec implemented?
Where I work, we have it easier. There are no specs to begin with.
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
How many projects you could afford to keep on the same solution?
Some blogs say it's 15-20. But this would be too little for large projects.
If I have to keep separate solution for different groups of projects (for the same product)
Then managing the dependency dlls breakage would be a nightmare.
How this is usually handled?
Lets say I have a Common.dll that's being used by 30 projects.
This means, I would prefer to keep all the 30 projects under the same solution (this is a bad idea?)
(I had seen people copy the Common.dll project into their own solution just to ensure the build is going easy  , but these are freshers)
So I'm trying to heap the projects under single solution.
And to keep the build process easy, I'm thinking to:
1. un-check the projects that are not involved in current build, in solution build settings.
2. Unload project itself if it's a POC, tester or something completely not needed for current build.
Am I doing this right?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
|
|
|
|
|
I have a solution with about 50 - 60 projects in it. I have never explored the maximum, if there is one at all beyond reasonable memory limitations.
The whole thing compiles to several executables, services and server components and many shared libraries for every tier/layer.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
CodeWraith wrote: I have a solution with about 50 - 60 projects in it.
|
|
|
|
|
I guess Nuget would be a solution as said by Sander Rossel?
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
|
|
|
|
|
Probably not. Except for the usual .Net framework stuff, there is only one single external library. The rest is my own code. Two applications, a graphics engine and a UI for the graphics engine, a web application for user management and login, six services, modules with entities, modules of application logic or data access 'behind' the services...
It sums up very quickly, but some of the older stuff (like the webpages for the actual applications) are on their way out once everything has been ported to the clients.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
|
|
|
|
|
Well i for my self separate as much as possible, my main project now counts 27 project in one solution. CUrrently Testing Projects are in there but i'll change that later on.
Every time i use a .dll from this main project in another i copy it to the new solution / project because the software does something else but needs some basic .dll's. (by copy i mean integrate it from the main .dll folder and set local copy true)
On the CI / deploy machine everything is linked therefore. Another benefit is, changes to your mainproject do not necessarily effect your other applications using the changed .dll.
Sure you have to keep track of things and manage a bit but i'd say it's worth the effort on long term since if you have a CI server and you configure it correctly the magic just happens and it works fine.
And it just looks awesome when builds run through their stages on the CI and you can just watch how it fluently goes through every section.
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
|
|
|
|
|
My current solution has 74 projects in it. Not something that is either practical or recommended, but in my defense, I didn't create the project structure. Microsoft did, so that explains that! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
modified 7-Sep-18 4:16am.
|
|
|
|
|
Johnny J. wrote: 74 projects
I'm not alone. Feels good haha
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
|
|
|
|
|
I prefer to keep it as few as possible.
Every application gets its own separate solution.
Shared libraries get their own solution and go in a NuGet repository.
The most projects in a single solution I currently have is like 10.
Most I've ever had is probably more like 15-20, as you say.
With microservices the number of projects in a single solution has gone down even further.
The pros are, of course, faster loading and building times and smaller and faster pulls from source controls.
The only downside I see is that it's sometimes difficult to develop multiple solutions at the same time, especially with microservices where one is dependent on the other.
|
|
|
|
|
Sander Rossel wrote: The only downside I see is that it's sometimes difficult to develop multiple solutions at the same time
To develop multiple solutions, what I do is add a temporary project in one solution change the reference to the temp dll and develop there. After the development is complete I just report the changes to the other solution and change the reference back to the original dll.
30 mins of extra work reduce a considerable amount of cuss words.
|
|
|
|
|
Yeah, I do that too sometimes
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
