tag:blogger.com,1999:blog-5028009537158799436.comments2023-07-10T04:50:03.236-07:00Building Real SoftwareJim Birdhttp://www.blogger.com/profile/17371102366836131341noreply@blogger.comBlogger428125tag:blogger.com,1999:blog-5028009537158799436.post-42018646256426765392018-04-02T10:13:45.100-07:002018-04-02T10:13:45.100-07:00@AndD: you could try just about anything to break ...@AndD: you could try just about anything to break that class out. Whatever you do will help make the problem simpler. Start doing it now.Jim Birdhttps://www.blogger.com/profile/17371102366836131341noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-7040316040509358042018-03-28T22:39:38.592-07:002018-03-28T22:39:38.592-07:00What approach i should follow to refactor my class...What approach i should follow to refactor my class if it already have 40,000 lines of code and i need to add moreAndDhttps://www.blogger.com/profile/10385225962819855239noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-81797707489596176662018-03-21T01:53:35.343-07:002018-03-21T01:53:35.343-07:00This comment has been removed by the author.soumyahttps://www.blogger.com/profile/13216393854011085887noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-65161144126659410012018-03-13T22:12:59.304-07:002018-03-13T22:12:59.304-07:00Another type of technical debt is the lack of atte...Another type of technical debt is the lack of attention to separation of concerns. This is a software constrcution/design problem, related to architectural problems, but not identical.<br /><br />I've seen code that interleaves networking, concurrency, database access, business logic, user interface, logging, input validation and and error handling, just rambling procedural code dressed up as faux object orientation or other architectural style, but completely missing the fundamental concepts of high cohesion and low coupling.<br /><br />Not only are bugs hard to fix because of ripple effects, it can be nearly impossible to change underlying libraries or services or move to another platform.<br /><br />Such code can otherwise follows naming conventions, be organized as 'classes' or whatever, but in fact it's just a brittle and unmaintainable mess.<br /><br />And that's a heavy debt load to carry indeed.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-62401647180769733122018-03-09T00:21:19.161-08:002018-03-09T00:21:19.161-08:00Great post !Great post !Rémi BOURGARELhttps://www.blogger.com/profile/04893916371648676071noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-5251041835192995312017-11-06T11:10:46.850-08:002017-11-06T11:10:46.850-08:00Going through the pain of Agile and application se...Going through the pain of Agile and application security. Great content in your presentation. Thanks for posting. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-39982255117179219852017-10-23T10:44:08.500-07:002017-10-23T10:44:08.500-07:00Another obstacle - data analysts.
With enough m...Another obstacle - data analysts. <br /><br />With enough manpower and process automation, you could conceivably have analysts with no access to the internet, no local admin rights, no code deployment rights, and only obfuscated data, but the cost would be prohibitive.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-10464462239721486862017-09-29T15:36:48.590-07:002017-09-29T15:36:48.590-07:00It might not be so wrong to split it if each chann...It might not be so wrong to split it if each channel has different needs. This sounds like a classic case of trying to maintain a global domain model. It does depend, but you are in an enterprise environment rather than producing for public consumption. I've found that different departments in an enterprise have different definitions and completely different use cases/logic for the same entity (Employee for example). Perhaps you can make channel services that extend existing services when it becomes so much of a problem - better than fighting to maintain a globally unified model with irrelevant data and properties on it. Hope that helps ease the pain :)@philn5dhttps://www.blogger.com/profile/13741152072729675553noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-48597811332174726242017-07-27T12:58:56.280-07:002017-07-27T12:58:56.280-07:00In our enterprise, there are generic data services...In our enterprise, there are generic data services used by several departments. Each department asks for enhancements on these services.<br />There are times that the enhancements are finalised within the same week and to be released in that weeks release train.<br />But each department(user) wants to test it all to make sure the enhancement from other department did not break the service. <br />Thus, until both department's own QA agree on the results, the service can't be released. (Thus creating inter department decencies). <br />How to resolve this issue? <br />They ask me to split the service so that each channel has its own service to maintain. <br />But that is wrong approach as this will not be a generic micro service but project level service per user/customer. One option is to make one department to wait for the next release but that also delays the time to market. <br /><br />Is there any options other than using feature toggles? I think, toggles are difficult to maintain...<br />Thanks...Cengiz Kayayhttps://www.blogger.com/profile/09989946110412455728noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-74272708456499196262017-04-13T12:57:13.648-07:002017-04-13T12:57:13.648-07:00This comment has been removed by a blog administrator.Adeelhttps://www.blogger.com/profile/04345121531607450313noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-62948361743979422222017-03-10T07:23:23.109-08:002017-03-10T07:23:23.109-08:00The main issue with developers that have defensive...The main issue with developers that have defensive style practices is that they don't know how to set boundaries, how to avoid their dependencies knowing too much on how the are used and they try to predict too much on what other people might implement and inject inside that will break their code. While things are actually really simple - developer needs to validate it's entry points very defensively in order to block invalid execution, and everything inside should be per contract. Trusted. <br /><br />If one can't trust own colleagues (current and future) that is a completely different problem.<br />Snoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-29715461001091987872017-01-28T03:11:25.835-08:002017-01-28T03:11:25.835-08:00^^ totally gets it.^^ totally gets it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-56757624533787250832016-08-11T18:58:17.191-07:002016-08-11T18:58:17.191-07:00I have to ask, what is the alternative? Ask the cu...I have to ask, what is the alternative? Ask the customer for 4 months to rewrite the software, or continue to add features as needed, which is what agile offers. What is the suggested alternative to agile? -WHAnonymoushttps://www.blogger.com/profile/12013318404569409634noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-39701309572523523672016-06-28T14:56:44.172-07:002016-06-28T14:56:44.172-07:00Great Article, in my experience whenever things st...Great Article, in my experience whenever things start going off track its, because there is no common reference designAnonymoushttps://www.blogger.com/profile/03131278807296438334noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-84276541965973946152016-06-16T09:31:02.497-07:002016-06-16T09:31:02.497-07:00@Ben Thompson,
Cool. Thank you for the data on che...@Ben Thompson,<br />Cool. Thank you for the data on check-in frequency and size. Makes sense.Jim Birdhttps://www.blogger.com/profile/17371102366836131341noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-27641637490492135302016-06-15T16:21:51.013-07:002016-06-15T16:21:51.013-07:00Jim, nice summary of an interesting problem.
Agr...Jim, nice summary of an interesting problem. <br /><br />Agree with you that you <i>can</i> measure developer productivity. <br /><br />GitPrime published some interesting data about work patterns of software engineers: it turns out that <a href="http://blog.gitprime.com/check-in-frequency-and-codebase-impact-the-surprising-correlation/" rel="nofollow">Prolific engineers take small bites</a> there's a direct correlation between the frequency someone checks in code and their overall impact.<br /><br />Thought you might be interested.Ben Thompsonhttp://gitprime.comnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-15484562671098124922016-06-13T00:31:25.839-07:002016-06-13T00:31:25.839-07:00Yes I totally agree with your rules. These are ver...Yes I totally agree with your rules. These are very important rule in any software development company. We at Cryptex follow standard rule of <a href="http://www.cryptextechnologies.com/methodologies/agile" rel="nofollow"><b>agile development software</b></a>.Anonymoushttps://www.blogger.com/profile/16286423335508501252noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-56155932826396286522016-05-06T08:15:14.448-07:002016-05-06T08:15:14.448-07:00Wow. This exactly the article i needed to make the...Wow. This exactly the article i needed to make the managers understand their role in an Agile team. Thank you Jim. This is a very good article.Rosshttps://www.blogger.com/profile/09096682080490418986noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-87859757227601305082016-05-02T23:02:11.020-07:002016-05-02T23:02:11.020-07:00Waterfall 20% functional 80% dead applicationsWaterfall 20% functional 80% dead applicationsAnonymoushttps://www.blogger.com/profile/04361455329486691839noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-61406687900242491682016-03-03T11:37:11.064-08:002016-03-03T11:37:11.064-08:00I have to agree with this, I worked for a place wh...I have to agree with this, I worked for a place where we had originally been overly cavalier in how we wrote code. This allowed us to get tons of functionality out quickly. But it created the problem of having an app that wasn't super reliable. Things would break a quite a bit. So we started moving toward writing better code. We started imposing coding standards and applying the boy scout rule. Initially writing code took about 4 times longer to get it live with our push toward better code. But then we started moving more and more toward the unattainable perfect code. Even our tests were expected to be written beautifully and perfectly. Our coding standards grew and grew and morphed every few weeks causing a lot of confusion in how a feature/fix/refactor should be done. By the end of my time there, something I would have before written in a week was taking me 3 months. I agonized over every piece of code and over my implementation of a refactor or bug fix. In code reviews my code would be torn apart repeatedly by multiple senior dev's with different opinions from one another. Oftentimes after 20 hours of work on a bug fix/code refactor they would end up wanting me to go a completely different direction.<br /><br />When a dev team starts chasing the perfect code unicorn it can really create a lot of problems and extreme slow down as each dev tries to get all code that gets written to look like their version of perfect. In the end every bit of code is written as if by a collective. The only way this could be efficient is if we had a hive mind. But we don't, so a dev team slows down to the pace of a single dev operating autonomously. But hey at least the code is perfect... from the collectives point of view. Until you hire another "Superstar" dev or an existing dev aquires new opinions through an article/book/video. Then these opinions must be melded into the collective. Now under the new collective opinion that code the previous collective thought was perfect... isn't anymore.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-44983500748766990702016-02-24T23:31:18.644-08:002016-02-24T23:31:18.644-08:00This comment has been removed by the author.Carol Jenningshttps://www.blogger.com/profile/10301690852524268341noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-24636135006891724602016-02-24T20:38:14.966-08:002016-02-24T20:38:14.966-08:00A project with 0 defects simply did not have exhau...A project with 0 defects simply did not have exhaustive enough testing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-21220728854792285662016-02-01T11:08:58.571-08:002016-02-01T11:08:58.571-08:00I agree with the Hardening sprint and it really is...I agree with the Hardening sprint and it really is very dependent on the complexity of the product, where the final RC build is validated along with other artifacts, like licensing and covers a end to end testing from downloading to activation. A challenge which we face is in case of encryption changes the export compliance approval is time consuming and getting that clearance take more time than to release in production. That is a legal requirement. Looking forward for suggestions.Susmitanoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-63724524579599337472015-10-29T05:43:38.969-07:002015-10-29T05:43:38.969-07:00@Jim Bird
You shared the details about your test ...@Jim Bird<br /><br />You shared the details about your test team of 3 members.<br />How many developers were working on the project?<br /><br />Thanks<br />Yakivayahttps://www.blogger.com/profile/08709665574074321928noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-54418315262133412232015-10-11T11:11:14.235-07:002015-10-11T11:11:14.235-07:00Jim, 100% share your learnings and observations. T...Jim, 100% share your learnings and observations. The recommendations in hindsight is good but in practice (depending on the size of the organisation) needs understanding from investors and customers the importance of time=value in the software development. <br /><br />It is interesting that the BIG ones evolved for 20 years to overcame their challenges, in spite of stashed cash and best software "engineering" brains. Only in the last four years, thanks to wide usage of mobile services which has helped the "consumer" to appreciate (and accept) the cost of delivering complex software. <br /><br />It would be amazing to understand the tribulations startups may be enduring with growing technology complexity and the extraordinary application of agile (little documentation) development to complex software programs.Anantha Narayanannoreply@blogger.com