Too Big for Spaghetti Code?
-
There is intresting inside look to Microsoft's Windows Vista development in Wall Street Journal - I guess it explains why Vista is late and why WinFS is not included: "Jim Allchin, a senior Microsoft Corp. executive, walked into Bill Gates's office here one day in July last year to deliver a bombshell about the next generation of Microsoft Windows. "It's not going to work," Mr. Allchin says he told the Microsoft chairman. The new version, code-named Longhorn, was so complex its writers would never be able to make it run properly. The news got even worse: Longhorn was irredeemable because Microsoft engineers were building it just as they had always built software. Throughout its history, Microsoft had let thousands of programmers each produce their own piece of computer code, then stitched it together into one sprawling program. Now, Mr. Allchin argued, the jig was up. Microsoft needed to start over." Entire article: Code Red: Battling Google, Microsoft Changes How It Builds Software[^]. It is allways intresting to read how other companies are working in their software projects and compare their experience to my experience. I have had "pleasure" work with small company that had maybe 2-3 programmers in single project and with huge company that had hundrends programmers working in multi-site-multi-country-multi-culture "project". My practical experience is that it is perfectly fine to work with 2-3 programmers without any coding conventions, reviews or other good practices. You can produce "good enough" code fast enough (=economically). Only what you need do to have is prioritized feature list, that you can use to share work actions between programmers and in negotations with project's sponsors. You don't need to pay much attention to software architecture. Biggest drawback is that project knowledge stays in programmers brains. If important lead programmer leaves company - your software development is stopped for next 6 month (good salary negotation tactic ;P). In one huge company we first developed software arhitecture with "core", basic concepts and component framework. Other programmers then started to add their code as components (one programmer normally coded one component). There wasn't any control what was inside components. Co
-
There is intresting inside look to Microsoft's Windows Vista development in Wall Street Journal - I guess it explains why Vista is late and why WinFS is not included: "Jim Allchin, a senior Microsoft Corp. executive, walked into Bill Gates's office here one day in July last year to deliver a bombshell about the next generation of Microsoft Windows. "It's not going to work," Mr. Allchin says he told the Microsoft chairman. The new version, code-named Longhorn, was so complex its writers would never be able to make it run properly. The news got even worse: Longhorn was irredeemable because Microsoft engineers were building it just as they had always built software. Throughout its history, Microsoft had let thousands of programmers each produce their own piece of computer code, then stitched it together into one sprawling program. Now, Mr. Allchin argued, the jig was up. Microsoft needed to start over." Entire article: Code Red: Battling Google, Microsoft Changes How It Builds Software[^]. It is allways intresting to read how other companies are working in their software projects and compare their experience to my experience. I have had "pleasure" work with small company that had maybe 2-3 programmers in single project and with huge company that had hundrends programmers working in multi-site-multi-country-multi-culture "project". My practical experience is that it is perfectly fine to work with 2-3 programmers without any coding conventions, reviews or other good practices. You can produce "good enough" code fast enough (=economically). Only what you need do to have is prioritized feature list, that you can use to share work actions between programmers and in negotations with project's sponsors. You don't need to pay much attention to software architecture. Biggest drawback is that project knowledge stays in programmers brains. If important lead programmer leaves company - your software development is stopped for next 6 month (good salary negotation tactic ;P). In one huge company we first developed software arhitecture with "core", basic concepts and component framework. Other programmers then started to add their code as components (one programmer normally coded one component). There wasn't any control what was inside components. Co
I work in a group of now 3 programmers. We have required architecture documents showing how all the prices work together and interact. We then have to write the code to a standard and test it We then have to get it reviewed by another team member before it makes it into the source safe database. Because we have been doing this, I must say that the quality of the product has improved dramatically. Do it. It makes life easier for you and your future workers. Plus you get a better product in the end. If you vote me down, my score will only get lower
-
There is intresting inside look to Microsoft's Windows Vista development in Wall Street Journal - I guess it explains why Vista is late and why WinFS is not included: "Jim Allchin, a senior Microsoft Corp. executive, walked into Bill Gates's office here one day in July last year to deliver a bombshell about the next generation of Microsoft Windows. "It's not going to work," Mr. Allchin says he told the Microsoft chairman. The new version, code-named Longhorn, was so complex its writers would never be able to make it run properly. The news got even worse: Longhorn was irredeemable because Microsoft engineers were building it just as they had always built software. Throughout its history, Microsoft had let thousands of programmers each produce their own piece of computer code, then stitched it together into one sprawling program. Now, Mr. Allchin argued, the jig was up. Microsoft needed to start over." Entire article: Code Red: Battling Google, Microsoft Changes How It Builds Software[^]. It is allways intresting to read how other companies are working in their software projects and compare their experience to my experience. I have had "pleasure" work with small company that had maybe 2-3 programmers in single project and with huge company that had hundrends programmers working in multi-site-multi-country-multi-culture "project". My practical experience is that it is perfectly fine to work with 2-3 programmers without any coding conventions, reviews or other good practices. You can produce "good enough" code fast enough (=economically). Only what you need do to have is prioritized feature list, that you can use to share work actions between programmers and in negotations with project's sponsors. You don't need to pay much attention to software architecture. Biggest drawback is that project knowledge stays in programmers brains. If important lead programmer leaves company - your software development is stopped for next 6 month (good salary negotation tactic ;P). In one huge company we first developed software arhitecture with "core", basic concepts and component framework. Other programmers then started to add their code as components (one programmer normally coded one component). There wasn't any control what was inside components. Co
Mikko Puonti wrote: My practical experience is that it is perfectly fine to work with 2-3 programmers without any coding conventions, reviews or other good practices. You can produce "good enough" code fast enough (=economically). There must be something wrong with the way I code. I’m huge on standards, when I find a better method; I do a code freeze and modify the entire app to fit into that standard (I know what your thinking and yes this has caused problems, but if it ends up improving the code then oh well). It’s the only advantage of being a one man show. Mikko Puonti wrote: If important lead programmer leaves company - your software development is stopped for next 6 month (good salary negotation tactic ). Not where I work, they know I'm leaving. No one has shown any interest in learning how to administrate my application. Their loss… Besides the app is mine, I wrote it at home on my time with my IDEs. hehe Mikko Puonti wrote: Eventually when there was something like 100+ DLLs in system you really needed to start thinking practical consequences from your development strategy. When you started to integrate components together, you needed to look inside components Sounds like a potential for HUGE code bloat. As the soul developer where I am its easy to keep things together. It’s just a real pain when I run into a design question as there is no one to bounce ideas off of. Mikko Puonti wrote: I think that I could shepherd maybe 5-6 average programmers without official, forced and standardised pratices. What ever happened to self discipline? I’m mean is it that rare now a days that people just try their hardest to produce the highest quality product they can? Nobodies’ perfect but forced? Standards yes! ------------------------------- DEBUGGING : Removing the needles from the haystack.