tag:blogger.com,1999:blog-4109745986470379872.comments2023-11-02T09:25:06.888+00:00The Cargo Cult that is software developmentSpeakingStoneshttp://www.blogger.com/profile/17043840914161199039noreply@blogger.comBlogger26125tag:blogger.com,1999:blog-4109745986470379872.post-66302644156075081602018-11-29T10:55:26.722+00:002018-11-29T10:55:26.722+00:00The blog is so enchanting. You just can’t be resis...The blog is so enchanting. You just can’t be resistant to it.<br /><a href="http://www.cargocarrierbox.com" rel="nofollow">suv cargo carrier</a><br />Seo Loverhttps://www.blogger.com/profile/07995966019272909961noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-39597095001758033072017-07-21T19:51:46.202+01:002017-07-21T19:51:46.202+01:00don’t have access to a big enough test system to r...don’t have access to a big enough test system to run high load scenarios before they get to production. <a href="http://www.kodux.com/" rel="nofollow"> kodu</a><br />Anonymoushttps://www.blogger.com/profile/12819340383697554523noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-1198258008615065442015-03-18T21:32:59.308+00:002015-03-18T21:32:59.308+00:00Fighting the same battle man! All hail SOA and the...Fighting the same battle man! All hail SOA and the other assorted silver bullets!<br /><br />It's nice to see someone else who is like-minded.<br /><br />The worst part is, if you don't embrace their assorted architecture puke they put you in the same camp as the spaghetti code writers who completely ignore architecture.<br /><br />Anyway, I hope you step up your writing frequency, I've enjoyed reading your posts.Brenthttps://www.blogger.com/profile/12901440807594885312noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-50812055641945380132012-05-21T18:14:20.135+01:002012-05-21T18:14:20.135+01:00Hi @Gesh, thanks for your comment, the K in KPI is...Hi @Gesh, thanks for your comment, the K in KPI is where the skill of the developer and their team comes in. The developer uses their own experience and other peoples input and feedback from seeing the dashboards to create better and better performance indicators. This iterative approach leads you towards the holy grail of Key Performance Indicators. Start with basic things like I described and add more and more things as the system develops. it makes everyone involved think differently about the task at hand. Not just code but actual real performance of the system.<br /><br />Possible outcomes of this approach:<br />Developer #57 - "hmm I cant get the KPI I want, why? hmm .... the system doesn't interact with system Z as we expected. We need a rethink of our approach here!" <br /><br />The great thing is this happened before it even got to testing. The developers flagged it themselves. Massive Win!SpeakingStoneshttps://www.blogger.com/profile/17043840914161199039noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-12064902130123951752012-05-17T18:28:43.431+01:002012-05-17T18:28:43.431+01:00From an Engineer on the ground perspective. The i...From an Engineer on the ground perspective. The issue tends to be the K in KPI. You just want performance Indicators. You can't necessarily tell what is Key until you see all the things you think may be relevant. This is a great post it describes what I've been shooting at for a long time!Geshhttps://www.blogger.com/profile/07480146046928721919noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-68052216596978964382012-05-10T16:56:34.871+01:002012-05-10T16:56:34.871+01:00Hi Khash, its definitely better to stop it at the ...Hi Khash, its definitely better to stop it at the source if possible :)<br />However PDD it what made it work in the end. Once we had the KPI dashboard we could easily see the bottlenecks and show the non tech people what was going on. Then it was much easier to reason with them, and discuss what was possible and what wasn't via the PDD dashboard.<br /><br />Remember the dashboard development was iterative, so it quickly showed the issues that existed as we built the system. It managed to force a change in thinking by the high priests. Thats a big win for everyone.SpeakingStoneshttps://www.blogger.com/profile/17043840914161199039noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-64101868994292033922012-05-09T10:44:25.024+01:002012-05-09T10:44:25.024+01:00I remember a discussion with the high priests when...I remember a discussion with the high priests when this "very complex modelling cache" was in the code base, revolving around the question of "let's think about it: do we actually need this?, do we actually need real-time modelling?". Do your PDD KPIs help with situations like that? ;-)Khashhttps://www.blogger.com/profile/08131292213155358714noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-40808094500859643562012-05-09T10:40:57.515+01:002012-05-09T10:40:57.515+01:00You reply to spams?!You reply to spams?!Khashhttps://www.blogger.com/profile/08131292213155358714noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-58218821948819096552012-04-28T13:12:45.393+01:002012-04-28T13:12:45.393+01:00Thanks for the feedback, glad you liked it.Thanks for the feedback, glad you liked it.SpeakingStoneshttps://www.blogger.com/profile/17043840914161199039noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-72675470203336071582011-08-03T20:42:37.820+01:002011-08-03T20:42:37.820+01:00"It is interesting that you stick up for Wpf/..."It is interesting that you stick up for Wpf/MVVM when it is pretty common knowledge that it is a flawed and dead product. Since I wrote this blog Microsoft has effectively abandoned it."<br /><br />I would challenge you to support either of those statements with evidence, as I have been heavily involved with WPF for the last year and I see no evidence that WPF or MVVM are dead (MVVM was a community invention to begin with, and was never explicitly adopted by Microsoft; so the idea that they "abandoned" it doesn't make much sense).<br /><br />I have read a lot about Evernote switching to "good old C++", and it is pretty clear that there were all C++ programmers who tried to make the jump to .NET, because they could see C++ getting left behind. They failed to fully understand either the .NET platform or WPF - both of which admittedly have a significant learning curve - and therefore it is no surprise that they failed to make the most out of either. Though they tried to blame it on WPF, retreating to C++ was a sign of their own failure, not that of the technology.David Nelsonhttps://www.blogger.com/profile/02439589027804976861noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-18815891967814952342011-08-03T17:35:25.409+01:002011-08-03T17:35:25.409+01:00Hi David, thanks for your feedback. It is interest...Hi David, thanks for your feedback. It is interesting that you stick up for Wpf/MVVM when it is pretty common knowledge that it is a flawed and dead product. Since I wrote this blog Microsoft has effectively abandoned it. <br /><br />As for other GUI technologies, I have been writing some Ios Apps lately and even though objective C is pretty horrible, it has let me produce beautiful applications that run silky smooth with minimal fuss. That's what I want on windows, smooth, fast, responsive Apps. Wpf is incapable of delivering this, just look at Evernote4. They tried wpf for years but eventually abandoned it for good old c++. The Reason? They couldn't get performance and it used to many resources. Thats microsoft all over really and I have used their stuff for years. HTML5 is the new Microsoft direction, light weight and portable. Something in between this and wpf would suit me.SpeakingStoneshttps://www.blogger.com/profile/17043840914161199039noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-73784484787632604042011-07-26T23:51:08.728+01:002011-07-26T23:51:08.728+01:00I'm sorry, but whatever it is that you have be...I'm sorry, but whatever it is that you have been using, it's not MVVM.<br /><br />I have been creating client applications with WPF and MVVM for over a year, sometimes using various MVVM frameworks, sometimes simply following the pattern on my own. Not ONCE have I had to "create untyped XML files that contain free text view model names, property links, black magic bindings, mystical triggers, obscure commands, baffling templates and untraceable style overrides." Nor have I had to "create notification properties with untyped string names, cross your fingers observable collections, even more magical routed events and commands."<br /><br />You apparently don't even understand the point of MVVM. All it says is that the technology-dependent GUI code of the screen that directly interacts with the user (the "view") should be separated from the logical representation of the state and behavior of the screen the user is interacting with (the "view model"), so that you can implement the logic of the screen without having to worry about GUI-specific concerns. In that respect it is no different than any other pattern when encourages the concept of separation of concerns. It doesn't even really have anything to do with XAML. You can implement the MVVM pattern in WPF without writing a lick of XAML if you want to; I know, I have done it (although I wouldn't really want to again. despite what you say, XAML is useful for what it was originally designed for, i.e. "application markup". It is when you try to go beyond markup that it suffers. In that way it is very similar to HTML).<br /><br />"Is this where you saw windows development heading when you first did MFC 15+ years ago?"<br /><br />Absolutely it is. The power and flexibility we have now with WPF (and other GUI technologies, to be fair) is what makes me excited about being a programmer. I'm sorry that you seem to have looked at how far we have come and become scared of heights.David Nelsonhttps://www.blogger.com/profile/02439589027804976861noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-77163610891886429042011-01-25T09:49:35.201+00:002011-01-25T09:49:35.201+00:00I think you're getting better at having a go a...I think you're getting better at having a go at non-issues!Khashhttps://www.blogger.com/profile/01321680817602700446noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-91975596021151014142011-01-21T09:54:09.373+00:002011-01-21T09:54:09.373+00:00stick it to the man!stick it to the man!Imranhttps://www.blogger.com/profile/15747817618207459786noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-59751816625226977072011-01-20T23:37:49.166+00:002011-01-20T23:37:49.166+00:00I really liked this post. I know what you're t...I really liked this post. I know what you're talking about ... but I'm not one of these developers.<br /><br />:)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-5365218269909849592011-01-20T22:15:26.538+00:002011-01-20T22:15:26.538+00:00Anthony, I think some of the MVVM separation conce...Anthony, I think some of the MVVM separation concepts are a good thing, but I have been using these ideas for years. Also I certainly wouldn't say winforms or mfc are the solution either. <br /><br />However surely we should have a better system by now. I mean .NET winforms is nearly 10 years old and it's still heavily used because WPF never really took off. <br /><br />To answer the 'other programmers' comment I have just spent the last year with a team of 30 people building a very complex multi threaded trading GUI using pure MVVM in WPF, all done with binding and triggers and styles etc. I would say we are pushing WPF pretty hard, and it is working, but nothing like we had hoped. The viewmodel part is fine, its the binding and triggers that are painful, not too mention WPF performance. For me this is the issue, MVVM binding hides so much from you that you will always have performance issues on anything complex, so in the end you get slow memory hungry applications.<br /><br />WPF=slow at the best of times, more abstraction makes it worse. <br /><br />I have a question: <br />Is this where you saw windows development heading when you first did MFC 15+ years ago? <br />I would certainly have expected a lot better.SpeakingStoneshttps://www.blogger.com/profile/17043840914161199039noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-71990940529782429102010-12-05T15:58:41.225+00:002010-12-05T15:58:41.225+00:00I completely disagree.
For the past 13 years I ha...I completely disagree.<br /><br />For the past 13 years I have been building large complex application in MFC, Win32, and Windows Forms. In all of these, it was a pain to separate the UI from the actual code so it rarely was done. This lead to harder to maintain code. <br /><br />Now we are migrating to WPF using MVVM and the results are amazing. A large chunk of WinForms tedious UI code gets eliminated when moving to XAML and bindings. The separation of UI and ViewModel lets us do drastic changes to the UI without touching a single line of code. There's more sharing between our many window types by reusing ViewModels for different views. Everything is now easier to maintain and we do amazing things we couldn't even dream of with WinForms.<br /><br />I've met other programmers share this author's opinion at my company, and each time, they were trying to follow MVVM without actually understanding WPF. They were trying to apply MVVM with a superficial "WinForms" approach to WPF, by ignoring bindings, and trying to construct their UI through code instead of XAML. They didn't understand how to properly use XAML data templates, template selectors, styles and triggers to really enforce the separation between the View and ViewModel. <br /><br />Of course that part is more complicated than just blindly manipulating your UI from code, WPF has a much steeper learning curve than WinForms. But I've yet to see a better pattern than MVVM to develop maintainable WPF apps.Anthony Brienhttps://www.blogger.com/profile/09915492438307290689noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-37207707640510260872010-11-19T13:58:12.182+00:002010-11-19T13:58:12.182+00:00Biggest troll post, ever ;)Biggest troll post, ever ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-22049437570933702662010-11-18T21:50:28.791+00:002010-11-18T21:50:28.791+00:00Very true, I cannot lay claim to that particular g...Very true, I cannot lay claim to that particular gem. However it still stands up as the defining description of the software industry as a whole.SpeakingStoneshttps://www.blogger.com/profile/17043840914161199039noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-65655001118412047842010-11-15T18:32:00.770+00:002010-11-15T18:32:00.770+00:00You're late to the name, Mr Speaking Stones: ...You're late to the name, Mr Speaking Stones: http://en.wikipedia.org/wiki/Cargo_cult_programmingJohn Barrdearhttps://www.blogger.com/profile/06125619745897907422noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-47540714172640232742010-11-11T13:44:22.756+00:002010-11-11T13:44:22.756+00:00The title of this is a bit misleading. As a reader...The title of this is a bit misleading. As a reader, I thought this would be about MVVM with perhaps some good alternatives presented, but really your issue is XAML and WPF itself.<br /><br />FTR, I really do like the XAML model. That's why I joined Microsoft.<br /><br />In WPF and Silverlight development, you should use *some* architectural pattern. I don't personally care what it is, but IMHO it should leverage binding. Many of the features in the platforms are easier to use with binding.<br /><br />MVVM happens to be a leading pattern. However, many people throw a lot of extra complexity into the definition of MVVM, burdening it with things that really are optional and confusing the community in the process.<br /><br />Before joining Microsoft, I wrote a good number of Silverlight applications, and a smaller number of WPF apps. Once we started using MVVM (and to be clear, we weren't religious about it), the code became much clearer and easier to understand. We didn't use an MVVM toolkit, we didn't adopt IOC in most cases, and didn't worry about mocking. We did test.<br /><br />I do agree that debugging binding, prior to VS2010 and .NET 4, was a real mess. It gets much easier in VS2010 when you turn on the options to show binding trace information.<br /><br />Performance issues you've mentioned have little to nothing to do with MVVM. With a couple exceptions around raising large numbers if INPC notifications and related (which we're addressing in WPF next), those are more about being smart about how much data you load, how you bind it, how you use virtualization etc. You'll run into the same issues when using LHS = RHS code rather than binding.<br /><br />Pete Brown<br />Microsoft Community PM WPF/SilverlightAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-24691909586446171262010-10-27T22:16:23.614+01:002010-10-27T22:16:23.614+01:00No doubt.No doubt.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-23453571746373992862010-10-27T14:56:46.452+01:002010-10-27T14:56:46.452+01:00i need to get an openid.i need to get an openid.Imranhttps://www.blogger.com/profile/15747817618207459786noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-85373413830843538272010-10-27T13:39:53.731+01:002010-10-27T13:39:53.731+01:00Even with this the c64 still managed to do paralla...Even with this the c64 still managed to do parallax scrolling!SpeakingStoneshttps://www.blogger.com/profile/17043840914161199039noreply@blogger.comtag:blogger.com,1999:blog-4109745986470379872.post-19854467882089015972010-10-27T09:34:14.493+01:002010-10-27T09:34:14.493+01:00C64 had 64K of memory. It's in the name, dude ...C64 had 64K of memory. It's in the name, dude :-P Although I seem to recall that after BASIC and all the rest had been loaded, you only had about 15K left to play with.Anonymousnoreply@blogger.com