Update & Share tips on Testing, Develoment, Design & Other New Tech Trends

Post Top Ad

Post Top Ad

Tuesday, July 25, 2017

July 25, 2017

Wegners Lemma and System Proposals Agility vs Ridgity

I do not have an extensive background in science. My soon wife does. She will have her PhD soon. In researching Scrum and Software Project Management, I ran into this thing called “Wegner’s lemma” and I asked her what a Lemma was. She asked if it wasn't one of those monkey-type animals. I told her she was thinking of a lemur, and realized that this is probably not science and should stop bothering her with more philosophy and theory that isn't about nano particles.


From what I can tell, a lemma is something that is assumed to be true so we can move forward under a given premise.

From Jeff Sutherland:

Wegner’s lemma - an interactive system can never be fully specified nor can it ever be fully tested. This is the software analogy to Godel’s theorem.

Godel theorem


And now I have to mention Godel’s theorem. A theorem is a bit stronger than a Lemma. It has been banged on my scientists and other smart people, accepted as true or at least, having merit.

What’s with the fear of commitment? I guess you cannot apply Scrum principles to mathematics or logic. I am a big fan of logic (Ayer, especially), and so I understand. What I dig about Ayer is his principle of nonsense. I am sure if my old Professors heard me call it that they would choke on their oatmeal, but Ayer says that any statement that cannot be proven true or false is nonsensical, and that every statement that can be proven true is a tautology. Makes good, tight, sense to me.
This is not wholly irrelevant to software engineering. Bear with me.

I am going to cop out a little here, because it give me a headache, but you can read about Godel’s theorem here. It has been extended into many different verticals, disciplines, and websites. It seems to be just short of a Law. If it interests you to understand it’s complexities, please pursue the aforementioned link. You will find many other links there.

Below, you can read about how all this applies to your approach at scoping a software System and creating a proposal.

Lots of clients want a firm proposal with a firm, fixed price. They probably have experience with manufacturing processes, and so the Waterfall approach makes sense to them. This understandable.

Software Engineering (new development), however, is not manufacturing. Unless you are prepared to eat potentially copious person hours of labor or fall short of customer expectations, you need to build a little slack into your proposal. This is classically done by using a multiplier, or by pricing iterations. Always seemed a little sneaky to me. The line item “Slack” reads like a co pout.

Software engineering defition


Wagner's lemma speak to the validity of an iterative process of discover, code, deliver; indeed, it was one of the arguments used to support and initiate the pursuit of Scrum before Scrum had been proven. Scrum is not new, contrary to popular belief. I mentioned in a previous post that we had something very similar to scrum at my family’s construction business, but it has been a software process for over ten years. It is finally getting real traction. If it did not work, you would not still be hearing about it. That’s the good thing about theories, I guess; if a theory proves to be bologna, you stop hearing about it pretty quickly.

You have three ways to approach a software proposal, if not more:


  • You can spec out a Big Up Front Requirements Phase and Development, QA, Implementation phases.
  • Similarly, you can spec out a Big Up Front Requirements phase that with speak to a more informed development phase, probably with iterations or a release schedule
  • you can argue Wagner's lemma and say that really, “we will not know what we are going to bump into until we bump into it, and as much as we have some historical information, your System is unique and to commit to anything besides something wholly unsatisfactory would be plain dishonest.” More formally, “your system will require an iterative approach, because when it is being developed, it will be done so within a dynamic environment that we would love you involved in so you can have transparency into the process and control over what is prioritized. Also, your system is new development, and there are many ways to approach it. We need to determine, along with you, what will work best. We are very good at building software, but equally important is our skill at building the *right* software”… or something. Give transparency into your process, deliver frequently, and this is palatable. “Rust me” rarely works in the absence of a bullet-poof reputation of long-standing relationship.

  • There are really two options: commit to a Contract or commit to a Contracted System. A contract is not flexible and does not benefit anyone when it asks them to commit to ambiguity. A System is much more robust.

    Here, we invoke Wegner’s lemma and our experience building software. Again, the requirements wind up being the source code.

    Of course, I think the best is a combination approach. Do some initial requirements so you are not playing code cowboy. Then, engage the client in an iterative approach, grounded in a proven iterative methodology (like Scrum or XP or MSF) and keep communication open. If your client is able to see progress, they will not see your function as a black box. And if you make them the Product Owner, allow them to prioitize features (user stories), they will not have to ask why they do not have feature X yet. They will have asked for features D and E and delayed feature X in a calculated decision.
    PS: As an asid, I’d like to mention, I am not really digging this new version of WordPress under FireFox. It is slow as anything. Under Opera, it seems a lot better.


    Thursday, July 20, 2017

    July 20, 2017

    Software Testing Process For Both Manual And Automated Testing

    Mike Cohn and others divide testing into 4 types: Automated and Manual Testing, Automated, Manual, and Tool-Based. I suppose a footnote belongs here, but as this little tidbit is as much from experience and a variety of media as it is his book (I am not sure which one, sorry).


    Software Testing Process


    • Automated and Manual Testing involved prototyping, simulations, functional testing, and user story testing. I personally extend this to service testing (interface testing, touch point testing, etc). For all of these we have information driving acceptance criteria (did it pass?) and the creation of the test (what are we trying to do?) These lead to trackable bugs and potentially, issues. “Fail fast” is made easy by prototyping.
    • Automated Testing includes having a Continuous Integration server, Unit tests (this is looking at and optimizing actual code in an XP peer programming model or not and specifically not doing manual testing where you enter orders or send an email to multiple recipients), and Component testing (also done in Tool-driven testing if you have systems within the System configured in a way to allow for it). Your CPU and compiler will tell you a lot. Automatic processes should be set up so that they take place before anything goes live (or even into a sandbox environment). I have seen development shops where if one of these tests failed, a flashing red light went off and in Toyota’s “stop the line” fashion (“Everyone stop developing and look at this!”) people fix what is broken before taking one more step. These lead to trackable bugs and potentially, issues, however these are more likely to be pounced upon immediately because you do not want something icky in the soup, so to speak.
    • Manual testing is what we have been calling Unit testing: poking at the GUI, verifying data is validated, things work from a UX/UI perspective, UAT (User Acceptance Testing), and others. UAT is the most important in my opinion. The vendor shows the Client functionality and it either passes or fails. You can have formal acceptance criteria (unscrupulous vendors mandate defined and exact Scope as well as the leverage inherent in highly detailed acceptance criteria). When I am representing a Client who interfaces with vendors, I try to steer clear of hard acceptance criteria and change orders and instead I lean towards reality where things change even if they are correct according to original spec. Clients have had bugs marked as fixed before anyone at the Client even checked or were able to check. This creates haze, and bugs are lost among larger issues, and the excuse is valid, a natural extension of chaos. Vendors have professional responsibility, and this is not my opinion. A company I worked for lost a court case because they did not perform what the court considered part of their responsibility as a solutions provider: proper management of issues. That is why I stopped worked for development shops. Being honest and forthright costs consulting teams money because delivering something measurable that cannot remain the same but must pretend to hold shape will lead to change orders and cries of “OOS! (Out of Scope)” while defining the system in terms of what it has to do at a high level leaves room for change in ways that do not impact behavior. Maintenance contracts bring in a lot of revenue.
    • Finally, there is Tool-driven testing. This is load testing, security testing, and hardware testing. This is stuff that your point a tool at and let it crank away and come back with analysis. All projects have a front end that is connected to a back end (not ALL I guess) which is why separating the sites from SAP has always been something I have not understood and so Tool-driven testing is extremely important). Also in this group would be analytics, for SEO, SEM, E-commerce stats, etc).
    So I would first recommend enforcing a real, proper, full lifecycle SDLC (Agile if the project is new but if the project is not new, something as close to what exists) and in doing that, most of the testing problems will fall away because Test-Driven Development would catch the silly bugs and if stakeholders change their mind, they will get to weigh the cost of changing their mind before altering something that works.

    Find more information:



    I would recommend an iterative (every 2 weeks or maybe 3) process where the developers are testing before they say their code is ready and the tasks/bugs that make up the body of work are both large and small but always high in value. That means, in part, developers have to know what they are building against and to have UAT feedback come back to them through a Product Owner (the singular person who approves the list of features and bugs that are coming in the next release and has final Product signoff).

    I would also mandate a versioning tool like Subversion properly where you do not create a fork until there is a release or spawn a separate effort that will not be merged again down the line. Without proper version control, you can track bugs and issues all day and it will be rendered an exercise in futility if the software is not versioned correctly. There is a marked inability to define what code is shared and what code is not. Some like to track the version of the software where they found the bug. I find that annoying, because we are moving forward, always.

    Software Testing And Bug


    Bugs: There are a billion tracking tools out there. I like any of the automated tools besides Trac (meant for developers, when you look at who winds up using it). The main things we want to capture as a team where vendors have an appropriate level of visibility into the open issues and the ability to assign items (again, keeping the power within the Client instead of the black box of “we understand and you will see it next build”) are present in all of them, by and large. Again, ask a friend. For bugs I think small teams can use Excel but like the workflow and quick views as well as processes that can be enforced by many bug tracking systems.

    Identity Field: May not be visible to the user of an automated system, but if possible, I like to show it for purposes of quick reference.

    What caused the bug? Evidence, like narratives, screenshots, are important and maybe even critical. If it cannot be reproduced, it should not be presented as a bug unless it cannot be reproduced on another machine but can be reproduced on a singular, or set of, machines. This would be the place for Brower type, version, OS, etc (if needed).

    What can we call the bug? A summary of what is wrong.

    Who owns it? If it is to make the entry in the tracker more informative, to gather more information, to approve in an approval queue, or to fix, this “owner” may be almost any type of team member. Product Owner will or should give the final approval that it is not active.

    Wednesday, July 19, 2017

    July 19, 2017

    A Paradigm Shift in Semantic Web Deployment

    I am a big proponent of all things Semantic. I have a degree in Philosophy, and the Philosophy of Language was what held my interest over the years. Even the idea of Ontologies is something that I have somewhat of an emotional connection to; the relationship and existence of things within the world is partly a semantic question, partly an issue of theism, and partly a great big sticky ball of epistemological wax. The Semantic Web is obviously something that I support, not only because of how it would advance productivity, expand human knowledge, and connect Systems. The main reason I dig it so much is that it could create something truly Good out of the WWW. It would help us make sense of all the data out there, stored in disparate Systems, strewn about intranets, extranets, and the Internet.

    I don’t think there are many who would disagree that the Semantic Web *could* and maybe *would* change the world (or at least the way we operate within it, since the world is by it’s very nature ever-changing, right?). There are those who are cautiously optimistic and have laid down the framework that would be required if the Semantic Web is to become a reality. There are those who are ambivalent about data altogether, so long as Dancing With the Stars isn’t affected. There are also those entities, such as Google, who don’t outwardly support a Semantic Web, yet could have a massive effect in it’s becoming a reality and are benefiting from some version of an applied semantic web.

    The Semantic Web Deployment


    Google is not against the Semantic Web, in that they do not do anything to prevent it’s emergence, but as the Semantic Web would involve quite a paradigm shift, Google is not waving the flag as high as it could. Google has displayed a more pragmatic pessimism, while making a nice living with contextual ads. There are different flavors of semantics. The Semantic Web (with all caps) is a vision of Tim Berners-Lee, and it certainly could be a reality. Google has stated that people are too “incompetent” for it to become a reality, but I think that is a purposely misleading statement on their behalf.

    While I do not agree that it is “incompetence” that prevents the average Webmaster from implementing RDF and other Semantic tools, I do think that the web is going to change due to what makes life easier for Webmasters, business owners, and other stakeholders *now*. SilverLight is Microsoft’s new browser plugin, and it was suggested to me earlier this week that instead of web Developers writing HTML to please browsers and to render in FF or IE, they will be writing applications to deploy within plugins such as SilverLight. This is important. If the model changes so that Developers write for applications, there are many implications upon data and upon the WWW - web services and Semantic Web Services included.

    It makes sense. Take a look at all the functionality embedded within Visual Studio and try to argue that OOTB tools such as they are have less intrinsic value to the average business owner (with the average IT staff) than the Semantic Web. One has M$ behind it, along with all the immediate value it carries. The other has promises of collaboration and a future where machine agents do intelligent work for us.

    I will be frank, although I am sure that what I have to say isn’t going to be that popular: “Web 2.0″ is not all that interesting to businesses outside of advertising. Blogs are online diaries. Social Networking is people talking to people. Yes, these are severe and maybe unfair generalizations, but let’s face it; the people who are using Social Networking the most are not using it for purposes of facilitating business. Sites like Facebook and MySpace are immensely popular, but the folks who make money here are the advertisers and the sites themselves. The sites are akin to toys with massive billboards on the sides of them. This hasn’t been a movement towards a more valuable web, because there is no recognized authority, no Standardized Ontology, no substantive connection throughout. Work flows exist independent of Standards, and communication happens in proprietary space.
    Even Second Life with it’s Linden Dollars is dependant upon Visa, MasterCard, or some real entity with standards, insurance, true grounding and defined components to support it.

    Web 2.0 has not done a heck of a lot for business, itself. Google itself enjoyed “viral” popularity. Developers were using it before anyone. Kids were using Social Networking before LinkedIn was popular. Businesspeople are generally too busy to be futzing around with the “cool stuff” online. They spend their time with the “productive stuff” and now find that some of the cool stuff can be productive, if you planned ahead and positioned yourself correctly. Google plays very well towards the convenience factor. Have you seen Google Street View yet? It is COOL. Will it make the world a better place? I doubt it. Will it make Google more popular? You can bet on it.

    Meanwhile, business is being done on the web. Content Management Systems and Portals such as Joomla and Sharepoint will enable business. They have tremendous value to the business owner. They allow for Social Networking, collaboration, information sharing, but also have ecommerce capabilities (.NETcart and others) and help folks make money. They contain work flow management tools, to help folks run their businesses. They don’t have an immediate “wow” factor like Google Street View, but I sure think they are cool.

    Microsoft is Google’s obvious competitor for mastery of the Globe’s data. The Sharepoint Server 2007 platform is Microsoft’s newest offering. It is amazing. It can do amazing things. However, because it is so dynamic and renders so much on the fly MOSS is not totally Standards-compliant. This is a big deal. This says, “our tool is so good that Standards will just have to forgive us…”
    Standards must be preserved, however. And Microsoft would be wise to obviate a way to implement RDF or Semantic technologies.

    Web Developers and Architects have a variety of landscapes that they can paint. They can paint an Open Source landscape, where the edges are a little fuzzy but the population is enthusiastic and there are no secrets. They can paint a Microsoft or other proprietary landscape where things are very well defined, but expensive. They can act based on what they know in either one of these cases, drawing on .NET or PHP experience and deploy. They can deploy something that works for business, or something that works for Business. Either way, they are not wrong.

    Or Web Developers and Architects can look ahead towards things they do *not* know. It is true; many Webmasters don’t know HTML, much less how to wrap their data in RDF. There is little out there to entice them to do so. What the Semantic Web needs is endorsement - not in theory, but in practice. If either the Open Source community or Microsoft were to build Semantic Tools into their suites, it would be a heck of a lot easier for the Semantic Web to form. It needs that first stake in the ground.

    With Google moving as ominously as they are, it would appear to me that Microsoft would want to consider embracing W3C standards and building Semantic Web tools into SilverLight, MOSS, .NET while Google indexes and makes available Google Documents and other immediately free tools. Google is throwing a heck of a lot of free stuff out there, while owning it all. I do not want my WWW to be as Google dictates. I want it to work for me, for you, and for You. Google is a business. They provide a service. They also make some people very wealthy. I do not want the WWW to turn into a de facto proprietary landscape. That would not be good.

    Ironically, I think the way to avoid this may be to get THE proprietary system - Microsoft - to build in Semantic Tools and take the control of data away from the indexing machines.
    And let’s face it; data is not just bits, bytes, and text. It is meaningful.

    Maybe it isn’t quite as it seems Andrew Layman worked on the original RDF spec, and he is a Senior Program Manager at Microsoft. It would make sense to me that they were doing, behind the scenes, what Google is doing right in our faces - planning to run the WWW.

    As soon as we see SilverLight contain RDF tools, I will smile a little inside. People will be writing applications instead of HTML pages, and the applications will be a much better platform for schemas, Ontologies, and Semantics than a layer imposed onto HTML.

    Google already bought Applied Semantics - natural fodder for their AdSense platform, and can do very obvious things with context. I don’t like the way it is all unfolding. And forgive me, but I can’t put my finger on exactly why that is. Maybe I have the feeling that people are playing dumb.

    Tuesday, July 18, 2017

    July 18, 2017

    Thoughts on 7 Good Practices for Modeling Software Requirements


    These are 7 “Good Practices for Modeling Software Requirements”:



    I like the spirit of this. But for those who are in an Agile or XP environment, or for those who follow MSF, AUP, or other iterative frameworks, there are some things to consider. I am going to bring up some, but certainly not all, of these sorts of issues.

    In regard to 1. BRUF (Big Requirements Up Front) is not only time consuming and costly, but often somewhat wasteful. Requirements change as your stakeholders and clients learn about what they are getting. Most of the time, as a software consultant, part of your job is to help the client realize their vision or solve their problem via technology. This is normally an iterative process whether you approach it that way or not. If you define scope as the 10,000 ft. view of the project (perhaps a simple Context Diagram), then I like this very much. However, the author of this chart suggests doing this to ward off scope creep. Scope creep is GOING to happen. If it is billable or not is one question, but if it is going to happen is another. It is going to happen.

    Modelling software requirements analysis


    In regard to 2. Again, I have stressed this elsewhere in my blog, but I believe that you use what is useful. Documentation can drown you fairly easily. Keep it light, Barely Good Enough, and malleable.

    Recommendation for you :



    In regard to 3. Repeat of #2. If your developers have no idea what a State Machine diagram is, you are going to have to work with what they do know. Most folks can get the hang of simple Activity Diagrams fairly easily. In my experience, you cannot throw all these models on the table and have everyone respond (in a positive way). New concepts need to be introduced slowly, and as they alleviate pain points. I have seen many a PM fail as they come to an organization with a portfolio of templates. Templates, even, usually need to be customized. We are lucky in this field; all of our tools are malleable. That is, unless you are using something like Rational, in which case you can find malleability within a gargantuan and robust legacy.

    In regard to 4. I wholeheartedly agree, but wonder how this relates to the first item on the list. Your scope will speak to your requirements, and then, vice versa. This is iterative: RIP, JAD, what have you.

    In regard to 5. This presupposes BRUF, to a degree, or at least some kind of system for documenting requirements traceability. Lots of places I have worked had MS Office as their PM tool suite (minus MS Project). You can do this with Excel (and I really like Excel for doing this), but it is time consuming and might not always be required -particularly if you are in an Agile or XP environment. The key here, I think, is in managing traceability and not breaking the thread.

    In regard to 6. I like this one.
    In regard to 7. There is not always time for this. At the end of each timebox or build, or at each checkpoint or milestone, there is often a sense of urgency. That is one of the reasons to implement an iterative development cycle; it keeps everyone from becoming complacent.

    Read more about Sofware Engineering


    Monday, July 17, 2017

    July 17, 2017

    Differences between Product and Software Development Life Cycle

    I wish I have had more time to write. I have been busy with work, but it is almost equally important that I keep this thing current. At least, until the bills come.

    I have been working with Kanban and “safe” projects: project that I can estimate without difficulty based on past experience. With Scrum, it is a bit easier to map out sprints and assign estimations to User Stories in order to give an estimate. Every CFO will want an estimate (or a QUOTE, really).

    The PLC and SDLC


    And this is what I want to point out in what amounts to a very poor excuse of a blog update: I am finding that Kanban works great for projects once the development process can begin, but until then, the board is not very useful. This may be obvious, but really, I like to start at the very beginning for every effort and I have found that even my swimlanes are changing based on the Client. This winds up being a symptom of deliverables, as dictated by a contract or project plan. Yes, I still do project plans when I am asked to, which is usually. I stay high level, or as high as I can get away with to avoid making even hints at a promise I cannot keep, but I can bust out a GANTT chart if the situation calls for it and because people like them. In truth, it never hurts to have a big picture view on the wall, however much it changes. It is almost like a snapshot of the initial vision. Well, it is.


    Agile is a philosophy and not an SDLC or a PLC


    Since Agile is a philosophy and not an SDLC or a PLC, kanban fits nicely into an agile SDLC. Scrum extends a bit more into the PLC realm because of the structure and collaboration, scheduling, and metrics that it affords.

    Again, I am finding that having a full toolbox is not as important as knowing what tools to use. Estimates will come from experience, and not the kanban board. They will come from whatever formula you have leveraged against the scope of work you are looking at.

    Kanban aims to keep things moving and remove restrictions associated with sprints. It seems to do this well, but it also requires, in some cases, a little bee buzzing around and keeping an overall eye on things. Project Managers, there is still a use for you. PMs who only manage budget and resources as though a project is made of lego parts are not getting the full picture. The project is a living, breathing, flowing thing that kanban fits quite nicely with.

    It is interesting to me that as “traditionalists” resisted agilie, some “agilists” are resisting kanban. Most of the time, these are not really agilists, but Scrum or XP practitioners. There is a big difference. A very important difference.

    When a kanban flow begins, it also creates metrics. Unlike other methodologies, there is *mostly* new information gathered with these metrics. I am reminded of good old PMI when I say that these metrics become inputs into future estimates. Still, kanban does not create estimates and does not demand them. It only allows processes to flow.

    Difference between sdlc and pdlc


    A PLC,  pdlc product development life cycle is not an SDLC, and Agility is not Scrum or Kanban or anything in particular. I find it at once interesting and horribly bothersome that as more and more people are focusing on agile methods, two schools are forming; there are those who think Agile deserves and has a place for a maturity model, and there are those who are making things more and more simple, less formal, and just DOING. We start learning how to DO when we are young. Somehow, DOING got us to where we are. We did not predict every twist and turn, and few of us actually executed whatever plan we had in mind when we were in our early teens or even early college years. This is brilliant, and this is the way life works. Why should building software be any different? With Lean development, we learn to not have too much on our plate and only take what we need. With Scrum we learn to work as a team and keep moving forward knowing that we dont know everything. With Kanban we learn to keep it moving and lean on each other, as though the team is a body where sometimes, yeah, you can scratch your leg with your foot if your hands are busy.

    I love simplicity. It tends to creep into my mind often that the more complicated something is, the further from a central truth it is. I like truth. I like few integration points. I like the fact that kanban seems to be very good at DOING, and that it can be wrapped in whatever presentation layer is required. I think it belongs in every IT Project Management and IT Team Lead’s toolbox. Right next to the “I don’t know but will find out” and amorphous hat. Top shelf stuff.

    I am not a fan of sticky notes, though. This is a problem. They lose their stick too quick. Remember Fruit Stripe gum? Tasted great for about 15 minutes and then you kind of just chewed it. I get about 15 minutes out of a sticky note. Might have a bad batch? This is a fairly new expedition for me, but looking back, I cannot say I have ever had luck with sticky notes. Maybe that it a metaphor unto itself. I am far too sleepy to attempt that dissection at this moment.

    Point is, kanban as an SDLC wrapped in a custom PLC seems optimal to me at this moment.

    Sunday, July 16, 2017

    July 16, 2017

    Story about using Window and other Operating Systems

    Let me first state that professionals do, in fact, use Windows. That’s just a catchy title. Or rather, a controversial, flame inducing title. But people that use their computers at home and techs that repair PCs with Windows will tell you that everyone uses Windows. Very not true. Home users needing something for internet and E-mail and word processing use Windows. And sure, maybe it’s 90% of the market. But we professionals are a little different. We need something more. We have specialized tasks that Windows may not be best suited for.

    Compare the rate of using Window and Other Operating Systems

    My inspiration for writing this was an experience I had at Best Buy. I was looking to purchase a USB wireless network adapter for an older Macintosh still running 10.2.  The gentleman helping me proceeded to tell me that everyone hates Macs and nothing is compatible with them. I laughed and shrugged and said I liked them. As we spoke more, he asked me why I liked Macs. I shrugged again and said modestly, “Well, I’m an IT guy so I use it for a lot of things and so it’s kind of technical…” He said, “Oh no, go ahead…” I explained to him all the rich features of OS X and told him some of the applications I run and how much better it is on the Mac. He wasn’t all too familiar with what I was talking about, but nodded and conceded his unfamiliarity with that stuff. Later that day, I thought more about it and I speculated what he was probably using his computer for. And of course, I came up with gaming, internet, E-mail, word processing, and some media apps.

    Purchasing a PC at Best Buy


    Now you take a look at the workstations from IBM, Sun, Novell, and Apple and none of them run Windows. But let’s also take HP as an example. They sell Windows PCs from HP at Best Buy. What they don’t sell at Best Buy from HP is their workstations running Tru64, HP-UX, OpenVMS, and Linux.

    Scientists, graphic designers, architects… are they committed Windows users? A lot of them are needing some serious workstations that are good for people doing CAD/CAM, GIS, high performance technical visualization and defense application.

    And this isn’t just the case for workstations. In the world of servers, super computers, and mainframes Windows is not king. When people need to do serious work, they do not necessarily rely on Windows.

    Operating System with MAC


    I’ve found the only people telling me how Windows is better are PC technicians. Ones that spend most of their time piecing together PCs and formatting them to reinstall Windows in their professional life, and most of their time gaming and downloading pirated software from torrents in their personal life. Now, once again, professionals do use Windows. But professionals disproportionately use other operating systems.

    Top 500 Super ComputersLet’s look at some numbers. I’ll start with financial figures I grabbed from Wikipedia. Microsoft’s revenue from 2007 was $51.12 billion. Let’s compare that with Sun, Apple, Novell, and IBM. Sun had revenue of $13.873 billion in fiscal year of 2007. Apple was $24.01 billion. Novell was $1.2 billion from 2005. And IBM is listed as having revenue of $98.8 billion during the 2007 to 2008 fiscal year. Now of course, this doesn’t say much about Windows verses other operating systems. These companies sell a lot more than operating systems. But I think it’s food for thought, taken with a grain of salt, when considering these competitors sell operating systems other than Windows, and they’re doing quite well.

    So let’s now look at some figures for Windows usage.

    How about servers? Let’s look at web servers. (I’m going to make an assumption here and not bother doing the research. I’m going to assume that most computers running Apache are not running Windows. After all, why spend all that money on Windows with IIS, just to install Apache?) Currently, about 60% of the internet is Apache and only about 30% is IIS. Well below the oft quoted 90% of average users that use Windows.

    Of the top 500 super computers as of November of 2007, only 6 were running Windows. (Windows Compute Cluster Server 2003.) Linux is at the top of the list with 381 super computers using it. Redhat beats out Windows with 13. Mac OS X is even being run on 2 super computers. IBM’s AIX is running on 26 of them.

    Ultimately, what I think I’m trying to get at is Microsoft with Windows does not control the world.

    Saturday, July 15, 2017

    July 15, 2017

    Why we exist in this information technology world?

    Some companies consulting in the software space exist because they say they want to optimize the value of software as a general idea. They want to fine tune methodologies or products. Some want to sell you their product which is, of course, the best. Some have the answer for you before they even know what the problem is. Some say they want to help you make your vision a reality.

    We exist for a different reason. We have done those things as team members. We started this company with a purpose.

    Exist in the world of information technology

    We were started by an individual who had the misfortune of working for several small, highly profitable, yet sleazy development firms. That may be a bit harsh in some cases. Some had a very finely tuned approach to their tricks. Ambiguous Statement of Work that required Scope Change Orders just to make a line item mean something tangible. Some firms were just sloppy, and cost the Client more money because improper or no testing was done, discovery was an afterthought, or the payments were scheduled so that after the spec was done, it did not matter if the Client left because a big chunk of money was due.

    In all cases, the Client paid for what they, in reality, should have been able to trust their vendor to manage for them. You trust your Dentist to put sharp things in your mouth and you trust your portfolio manager to make the right decisions. You even trust your mailperson to not steal checks. Somehow, the world of software consulting has not adopted trust. Part of the reason is that we are building ideas, but I do not accept that as valid.

    Our founder grew up in a household with a family business. Construction. Dirty, oily, bleeding fingers and frozen toes were normal. We laughed about it and kept working when really, a “smart” person should have gone home – or so they say. What made that company successful was not that they made money on a deal as did the the aforementioned lucrative software firms but instead the fact that the owner of the company knew relationships are more important than deals. There is a human element in everything, because we are people (or most of us are…. I had this one boss I could see being from another planet…)

    Update to technocial revolution

    When that construction worker died in a motorcycle accident (my father), I received a gift. I got instructions as to what my life needed to amount to. I knew what I needed people to say at my funeral. I do not want to hear “he changed IT and revolutionized technology” (although, that would be nice) nearly as much as I want to hear Dad’s eulogy echoed: “His word was good, and those who were close to him had a friend, a partner, a confidante, and their lives were better off for it. If he shook your hand, it was as good as a Presidential decree. His family came first and to support that family, he relied on hard work, honesty, and perseverance. He was an honest and strong man who you could count on to be there for you, and the world will be worse without him. They do not make them like Greg anymore.”

    I am of that mold, and MiT Consultants exists to honor Gregory Milane as well as the heartbeat of your organization. With every move we make, Dad comes with us. For you, that means you get two generations of old school values coupled with cutting edge technology,  an almost insatiable need to be the best, and a purpose: help people who need help and add value wherever you can. Be a good man and represent something honorable. You get traditional values and strength of character along with a love of the emerging technologies.

    We have existed for a long time. We are more than a company. We are the heart and soul of my hero. If we let you down, I let him down. That is not going to happen.

    I know all the tricks and loopholes, risks and stumbling points. These will come your way as you embark upon your project. We can help guide you and protect you and truly be your technology partner. We take that idea to heart, to bed at night, and on vacation.

    Get in touch. Say hello. We are looking forward to hearing from you.

    Best Regards,

    Josh Milane

    Friday, July 14, 2017

    July 14, 2017

    Complex Adaptive Systems Are Everywhere

    I think a lot of people work for companies and then decide that they want to go off on their own and either do consulting or start their own businesses because they are not in situations where they are learning (which usually translates to they are not making enough money). Sure, there are isotope people with an idea that makes them not fit in with the rest of the nice, cyclical world, but more generally people are just prone to being dissatisfied. 

    Couples are dissatisfied too, but their dissatisfaction becomes their standard and “well, it could absolutely be worse. I am lucky.” If there was a widget they could grab onto that would take them to the next level, they would be grabbing, but if there was a widget they would have done what I did – and more on that later. Ask my wife (who is just over 5 feet tall): you can only reach so high without standing on something or getting a boost.

    Example of complex project management software

    Professionally, I was in a similar spot. I did not have an idea that translated into billions of dollars but I am a very large fellow with an amazingly hot wife that happens to be a Doctor, and so it is quite easy for me to feel adequate and not toss and turn at night thinking that I am somehow a failure as a man. Let me be clear; it is not that I am so smart. I am not so smart. I just work hard and do not have the option of failure. My personal life presents me with a uniquely challenging situation and I am at once constantly struggling to position myself for success and stay true to the tenets of professionalism while not becoming too academic (it is a hard line to see at times but I can show it to you - and I owe Scott Ambler a lot, so no disrepect). It is not that I am so smart. It is that within Project Management, Agility is not new. It is not cunning. It is not anything we did not do 15 years ago. It is plain old prosletyzing when people argue Scrum versus Kanban. I will tell you the answer; it depends. It always depends on the situation and all that comprises it. I will also tell you, there is no such thing as Project Management. We created it as an idea to describe a set of circumstances. It works, because we are a Complex Adaptive System. More on that (too much, maybe) soon.

    Project Managment exists on paper (this is an imaginary form that allows people to argue about nuances between RUP and RAD and so on and if there is value in a Scrum Master). If you read my blog you know I keep pointing to Ayer’s Universals versus Particulars. It is crucial. In my opinion. Please add this to your IT book shelf. People will look at you weird (if they do not already), but if I have learned anything it is to question even the obvious. Kids do it. We get them to stop. Shame.

    There is also Project Management as it exists as a bucket that catches tasks that need to be done – this is what we try to describe in a generic fasion – some of these things are known and some are unknown but all real and likely to manifest. Projects are Complex Adaptive Systems. Project Management is a CAS because it does not exist by itself except for in theory and unless you are a PMI-thumping zealot, you recognize that sometimes new things come along that do not fit into the plan and although PMI recently realized they had to accomodate for Agile, Project Management is still a CAS because technology is changing so rapidly and Project Managers exist within dynamic environments. It took me a long time to realize that up until a point you are learning and past that point, you are just bickering about inconsequential theory upon the imaginary. The “Thoughtleaders” make me cringe. That is not exactly true. The term makes me cringe. Honestly. Part of that is because they are called Thoughtleaders when they stray from the norm and this is unique to IT – you can be dead wrong but still be a Thoughtleader. If that is the case, hoo boy am I a Thoughtleader. Where is my book tour?

    People like the guys across the hall that do Scrum and do it well even though it might not be Scrum as Schwaber or Sutherland would call it are doing it right. They might not be Thoughleaders, but they are getting things done. They are plain old leaders. They are also a Team and a CAS. This is not to say Schwaber and Sutherland are not productive and important people. They are. They are brilliant, as is Scott Ambler and the rest of the guys I take pot shots at for fun and to see what might be uncovered. 

    However, Jane Doe who is learning Scrum by doing it or who is building an application in an extensible fashion is *just as* important and I would argue perhaps more important than those who had the initial spark of an idea. This is horrible to admit in public, but I have always had a problem with authority. You’re not the boss of me. Please, earn my respect before you expect it. Recognize that unless people call you their Leader and treat you as a Leader or see Leadership value within you, “Leader” is just like a Burger King crown you put on your head. Paper. Disposable. Fragile and common.

    So I was consulting. I had no sparks of ideas that translated to dollars outside my hourly fee although I dare say I loved working alongside brilliant people and solving problems together. I just was not learning. I would go to work and try things that I never tried before even if I had no indication they would work just to see if they would. I did it all in line with Best Practices, and I tempered it all with reality and responsibility, but there was nobody to say I was doing it wrong because in truth, it is not all on paper even if you try to put it all on paper and I have been afforded a lot of responsibility over the years, thankfully. I have had projects fail. I have had more succeed.

    I got on Twitter a few years back when nobody really knew what it was for (including myself) and totally overshared. You do not care that I just had a great steak dinner unless you were the cow. In fact, years later with Loopt and the like you would learn that I was at Great Steak Restaurant and then go rob my house because I was so accustomed to assuming the Leaders were truly leading that I was safe following them (I never personally did this, but many smart people did and continue to). The people who started Twitter loved that I told the world I just bought a toothbrush, but in reality, there is no value there except for in the fact that technology is a Complex Adaptive System and like a coral reef, will try new things and grow in that direction if nourished or fall off and die if not. The wildfires in CA showed the potential of Twitter and it adapted. Hashtags became standard. Having @joshuamilane on business cards (mine, at least) became commonplace.

    Things evolve, for good and bad depending on what side of the fence you are on. The Dodo bird was on the wrong side. Twitter was on the right side. People are things. These things are Complex Adaptive Systems. Tip from before I was married: if there are girls around and you want to impress them, you can talk about a CAS so they have to ask what you are talking about because who in their right mind does not swoon at acronyms – especially when used together – and who would not be totally turned on by the concept of a Complex Adaptive System? The great thing about three letter acronyms is that you can almost become a poet just by talking your lingo of choice.

    *Swoon*

    You get the point. Yes you do. There is no point. Without the ability to bring things together, we meander like a rivulet of baby boogies. There is direction somewhere (usually towards the mouth), but nobody is steering the ship. The ship must be steered, and Thoughtleaders are not steering. Great ideas implemented by regular people are steering, collectively, as a CAS.

    I can stand here with my arms at my side and look like a bull standing on his hind legs. Nobody will talk to me. I know this, trust me. If I say hello, however, one of two things will usually happen; I will hear “hello” back or that person will run. Once in awhile they will just ignore me. If I extend my hand, I have made a connection even if nobody takes it because they can recognize the potential for connection. If I just talk to you, I have made a connection. If I maintain that connection, it is akin to my growth. Our growth.

    How romantic, yes?

     The CAS gets larger. That is why, in my opinion, it is important we build things with extensibility in mind and with a solid foundation before we rush to slap the latest hot topic out of the box. I do not want Enterprise software that tells me how to display my tweets. I want to dictate that myself because I might change my mind.  I probably WILL change my mind eventually. I could build anything in software. Why build something that limits when the very nature of software and being human is to be part of a system that extends itself, grows, and as the future manifests, accomodates the world and it’s people? The Thoughleaders are not the ones who decide where we will go next because in the end, although they may sell books, there are checks and balances in place just as in nature and a few failures will spread into a buzz which will be louder than the prosletyzing salesperson. We dedide what is next. You and I do. The community does. Some roads are laid out for us and very attractive because they are soft and easy to walk down, but that does not make them good. That makes them marketable.

    Build with extensibility in mind. Build with the ability to itegrate in mind. Be Agile. Deliver value quickly. That is easier said than typed, really. If you build in a way that allows for web service calls, consumes and passes XML, operates under a service-oriented architecture (SOA for you who are still giddy from my poem), or otherwise takes advantage of the fact that we do not know yet then you are doing it right. from www.photoshoproadmap.com

    Remember Legos? A big pile of what looks like junk. How many units did it sell and how many types of Legos were made? You have Star Wars Legos, Construction Legos, Army Legos, and all sorts of others. All they do is allow you to build in an extensible fashion. This concept of waste or muda, specifically, is in my opinion off-base. If I have left over Legos but built something I love, the leftovers can either sit there happily useless or I can build something small out of them. You might be seeing that in a Complex Adaptive System, POTENTIAL is where the value and where the magic lies.

    I was not learning as a Project Manager. Could have been my fault. Could have been bad luck and a bad choice of situations to put myself into. Could have been that as a Consultant, it was because I knew Agile that they hired me. I was not being paid to learn (although I did learn about *other* things besides Project Management). Potential was low. I was losing my ability to grow a CAS, which is what your team is. Someone asked on Twitter (it was this guy) “Do we all accept that teamwork and team-oriented practices have proven themselves and finally triumphed over the lone-genius model? ” Because I like to push buttons and keep things interesting, and because as much as I think Bob (that guy) could write fortune cookies for a living, I asked if the Team could not be the Genius. He said no. He may have been kidding. Fact is, the team and the CAS is the Genius.

    Even if it is one person, it is their ability to connect that makes for genius. The validity of “genius” aside, we are talking value here. I could be a genius at stacking pop tarts and nobody will care except the guy who sells me pop tarts. I was, in fact, becoming really good at stacking pop tarts, but pop tarts made of concepts like Kanban, Scrum, Lean, etc. I love that stuff, don’t get me wrong, and I still very much enjoy helping Teams find their inner Agile, but it was getting academic.

    Which brings me to the point of this blog entry.

    I recently joined Sitecore as a Regional Sales Manager for New England. Yes, it is quite different than being an Agile or PM consultant. Hugely different. Keep you up at night different. However, there is a very good reason I did this. I know the value of a CAS and of being around people who are smarter than you. Sitecore grew 60 percent last year. Competition is nervous, and there really is none. Look at the Gartner Magic Quadrant and the .NET platforms this year. What joining this Team did was allow me to take what I was talking about for all my 16 years in software and actualize it not as back and forth over theory, but as an advocate for a tool that will make a real difference and allows for all the benefits of a CAS within a CMS / WCM.

    I am an Open Source fan, because well, it is open. The benefit of being open is extensibility and customization. Sitecore has that as well, but within the .NET framework. How many refactoring projects have I been on that were written in .PHP and wound up as dyspeptic (if digestable at all) spaghetti code? Probably 50. It is true that .ASP to ASP.NET can be hard, but Sitecore is ASP.NET, integrated with Visual Studio, and it does not hand you a solution and take away your ability to play with your Legos like so many do. It is powerful, but you are as powerful as it is. The other very cool thing about Sitecore as a company is they only implement (I guess I should say we only implement) through partners. If you are a Sitecore Partner, you must be good and you are able to focus on your job and the Client.  

    Okay, so let’s look back. We started very far from Sitecore. We wound up here. I did not predict this. I just knew I needed to write something in my blog because it has been awhile and there are people outside my house with signs screaming for an update. Yesterday someone threw a tomato and so I knew I had to sit down and write. It makes sense to write about what is relevant. Right now, I am kind of grooving on this whole “being part of a kickass team” thing. That, and some of Jimi Hendrix’s more eccletic work like “Third Stone from the Sun” (highly recommended, thank me later).

    The fact is that a well oiled machine does a lot more than any one of it’s pieces alone, but each piece has an important function. A Complex Adaptive System exists within each one of us. The lone Genius model never existed, although it did on paper (sorry @flowchainsensei). I have made the move from being a self-propelling agent of Agile to an agent of Agile who can point to an actual tool that helps BUILD instead of track projects. Learn about Sitecore and you will see why, but it is all about extensibility, being able to reach your hand out easily and integrate with another system, and being able to recognize not only who you are presenting a site to, but how they are viewing it, who they are, and how your site was made to be rendered for people. Not browsers, but people.

    If you want a demo, and you do… trust me… get in touch with me. If you are a .NET shop with talented developers, give me a little of your time. You have my word it will not be wasted. I am excited at this opportunity and think you will see why. I am choosing to get get into the acronym dance here because it will not have much value. I am choosing to not talk theory here because it will not have much value. I am talking about potential for the rapid delivery of value. I am staying Agile, but grounded. Not the lone genius by any means, I am suggesting that if you are curious why I would make such a significant change at a time of my life where I (really now) cannot afford to fail, let me know.  I will make sure you see. Until l saw I thought it was a song and dance.


    July 14, 2017

    Agile Development and Team Story

    It is true that within Agile you have the notion of being free of a set method and allowing the team to decide. I have heard all the arguments. Some say the team will not decide. Some say it does not work. Some say it works under certain conditions. Some say it works but only if the organization is ready. Scrum, by being a formal methodology, automatically negates what is at the heart of the Agile Manifesto and the Agile Manifesto is regarded as a kind of 10 Commandments of Agile Development but the truth is something altogether different.

    We did Agile development before it was called Agile development. My coining a phrase, you create an entity (real or not – you have heard of a Unicorn, no?) and by setting forth a method by which to accomplish the goals in mind such as Scrum does you in no way break any tenets.




    Agile is not unique to software. Nor is lean, Kanban, or any of the new buzzwords. They are buzzwords. They make enough money and generate enough revenue that PMI is starting to incorporate Agile methods in their PMBOK.

    A bunch of guys in a cabin in the woods is not necessary in this day and age and only serves to add to the mystique behind the Agile Manifesto. As far as I am concerned, people who write Manifestos in the woods are suspicious and up to something. Not all of them are planning on blowing something up. Some are just meeting so there will be no distractions. Yeah. Because it requires complete concentration to chase a Unicorn. You cannot do it head on, after all.

    I hate to say it, and I will hear about it, but Scrumban and all the over-intellectualization of what amounts to getting work done as a team is a symptom of big brains without enough to do. Or, and equally as valid, are those big brains who see the ability to make money off of the latest fad. It is nothing new, but the buzzwords are. There was always a brownie with less calories. It was not called a Light Brownie until someone marketed towards people who wanted a less fattening brownie. And that is all it is. Less fattening.

    I have wondered a bit about why this bothers me so much. In a world that does not seem to reward honesty, why would I insist on calling like I see it? Saying that I care sounds and even resonates a bit hollow because I really cannot care about you if I do not know you.

    I guess it boils down to a disdain for bullies. People throw words like punches and get all bent out of shape and worked up because of something as idiotic as what “done” means. Have we forgotten that everything is in context and everything has eyes upon it, therefore perspective, and that there is no judge without an opinion?

    Then there are those who think it really is important to define what done is aside from any actually physical project. I will tell you what it is: an idea. A Unicorn.

    Get your work done. Inform yourself. Learn. Be wrong once in awhile. Be honest even if it hurts. Scrum, Kanban, Lean, and the like are all meant to take your attention away from what they entail and that is delivering software. I did not say good software. There is no such thing. There is software that does what it is supposed to for some people and not others and there is software that plan stinks because nobody likes it.

    Do your best and keep learning and dont let the intellectuals bully you into thinking you need ScrumLeanBan in place. Muda… why do they use a Japanese word? Like the cabin, it makes things more mythical. It is what it is.