Tag Archives: software

Quote

On specific Agile (software development) traps

There’s much positive to be said about the benefits of Agile software development, and the shift of software development teams is one sign that many feel this way.

However, I think there are some limits to Agile, and this leads teams to fall into certain traps over and over. Indeed, the Wikipedia page highlights a common criticism of Agile, namely:

Lack of overall product design
A goal of agile software development is to focus more on producing working software and less on documentation. This is in contrast to waterfall models where the process is often highly controlled and minor changes to the system require significant revision of supporting documentation. However, this does not justify completely doing without any analysis or design at all. Failure to pay attention to design can cause a team to proceed rapidly at first but then to have significant rework required as they attempt to scale up the system. One of the key features of agile software development is that it is iterative. When done correctly design emerges as the system is developed and commonalities and opportunities for re-use are discovered.

Now, it’s not the case that teams either do design or not. But I have seen that there are a number of specific traps bigger that Agile teams fall into that arise from lack of design. These traps arise from making tactical or limited decisions outside of a larger framework or structure, which isn’t surprising since Agile followers are guided by the principles that the “best architectures, requirements, and designs emerge from self-organizing teams” and “working software is the primary measure of progress”. Unfortunately what I’ve seen that lead to is:

  • Poor middleware/database system decisions: with this trap, you get teams making a decision on deploying a specific middleware package or database system that will support the software development they are doing. However, while that may be great for the Dev, it may not be great for the Ops. If you have enough teams making tactical decisions, you may end up with a more complex system than is necessary and greater technical debt that you want. Once you get enough data into your database systems, trying to reverse the decision may result not result not only in new development and testing, but a small (or not so small) migration project as well.
  • Poor infrastructure decisions: likewise, with this Agile trap I have seen teams using IaaS pick different images to deploy their software onto. Like the database problem, developers may choose one operating system (e.g. Windows) over another (e.g. Debian) because they are comfortable with the former, even if the production environment is more of the latter. The result can be your organization ending up with multiple VMs with many different operating systems to support and thereby increasing the operational costs of the system.
  • Poor application framework decisions: I see less of this one, although it can happen where teams pick an assortment of application frameworks to use in creating their software, and as with middleware and infrastructure, this will drive up the support effort down the road.

Given these traps, I think the way to avoid them is to inject some specific design phases into the overall software development lifecycle. One way to do that is to revisit a software development lifecycle (see diagram below) used by practitioners at IBM and documented in places like this IBM redbook. It has a waterfall quality about it, but it doesn’t have to be limited to waterfall type projects. It can be highly iterative.

The lifecycle process is shown here (taken from the redbook):

 

GSMethod

The part of the lifecycle in the large box is iterative and not all that different from an agile sprint.  But here you take time to explicitly make design / architecture decisions before building  software. You continue to iterate while making important design decisions before building.

Now, before you start your iterative software development lifecycle, you should need to  make specific architectural decisions. You should make these specific decisions in the solution outline and macro design phase. For smaller teams, these two phases may blend into one. But it is here in solution outline and macro design where you make decisions that are fundamental to the overall solution.

For example, in solution outline you could make overall architectural decisions about the application architecture, the choice of infrastructure technology, what application frameworks are the target for the team. These overall architectural decisions guide the dev, test and ops teams in the future. You may also decide to park some of these decisions in order to do further discovery.  Macro design could be next, where each of the dev teams make certain design decisions about their technology choices before they proceed with their iterations. As they are building and deploying code, they can run into issues where they need to make further design decisions, either due to problems that arise or technology choices that have to finally be made: and this is where the micro design phase is useful.  Micro design decisions could be quickly made, or they may require spikes and proof of concepts before proceeding. Or there could be no decisions to be made at all.  The main thing is more design checkpoints are built into the development lifecycle, which can result in less complexity, less maintainability costs, and less technical debt down the road. What you lose in velocity you can make up in overall lower TCO (total cost of ownership).

There is a risks to this type of approach as well. For example, if the project gets hung up with trying to make design decisions instead of gather requirements and making working software. The key stakeholders need to be aware of this and push on the design teams to prevent that from happening. If anything, it can help the key stakeholders better understand the risks before getting too far down the road in terms of developing software. Overall I think the risks are worth it if it helps you avoid these common agile traps.

Quote

Truly great MacOS apps for working remotely

I’m often disappointed by lists of software that supposedly help me work better. This is not one of those lists. I think the tools here are really great, and anyone with a Mac that works remotely should definitely check out this:  These Are the 8 Best MacOS Apps for Working Remotely | Inc.com

Quote

Do you know someone who wants to learn how to code? (Maybe it is you!)

Then this is a good page for them to go to: How I Learned How To Code Using Free Resources | Home | Bri Limitless. 

There’s plenty of good links to information, and they are all free. I can vouch for a number of them, such as Codecademy and Coursera.

One problem people run into is: why should I learn to code? One obvious answer is to learn a set of skills to help them gain employment. Two other reasons I have:

  1. build a website to promote yourself or any future business you might have.
  2. automate things you do on your computer

For #1, being able to build a website is a great way to promote yourself and show yourself to the world. As for #2, that’s the main reason I still keep coding. There’s lots of information I want to process, personally and professionally, and coding is the best way to do that.

Regardless of your reason, if you want to learn to code, check out Bri Limitless’s web page.

Quote

MindMup 2: a good web based mindmapping too

I’m a fan of mindmapping tools in general. One I’ve been using and enjoying lately is MindMup 2. 

Two things I like about it:

  1. It’s simple to modify your mindmaps on the go. You don’t need to do much to add or modify your map.
  2. It’s also simple to export your mindmap into a number of different formats. If you occasionally use mindmaps or you want to start with a mindmap to generate ideas but then you want to do the majority of the work in Word or some other tool, this is a good feature.

Mindmup_2 is a good tool. Go map your thoughts.

Quote

Isn’t machine learning (ML) and Artificial Intelligence (AI) the same thing?


Nope. And this piece, Machine Learning Vs. Artificial Intelligence: How Are They Different?, does a nice job of reviewing them at a non-technical level. At the end, you should see the differences.

(The image, via g2crowd.com, also shows this nicely).

You need good work tools to be your best at work. Here’s 11 for you to consider


We all get in ruts where we use the same tools every day for our office work. When that happens, what we need is someone to come along with a new list of tools and what makes them great.

Here is such a list. I didn’t create it, but I have used 3 of the 11 tools here and I can say they are key to making me more productive every day. I plan to use the rest of them too, based on the description of them.

Sure, you can do fine with Microsoft Office tools. This list will help you do better: 11 Most Used Tools & Apps Essential to my Work – DESK Magazine

(Image via pexels.com)

34 good links on AI, ML, and robots (some taking jobs, some not)

If you are looking to build AI tech, or just learn about it, then you will find these interesting:

  1. Artificial intelligence pioneer says we need to start over – Axios – if Hinton says it, it is worth taking note
  2. Robots Will Take Fast-Food Jobs, But Not Because of Minimum Wage Hikes | Inverse – true. Economists need to stop making such a strong link here.
  3. Artificial Intelligence 101: How to Get Started | HackerEarth Blog – a good 101 piece
  4. Deep Learning Machine Teaches Itself Chess in 72 Hours, Plays at International Master Level – MIT Technology Review – the ability of tech to learn is accelerating.
  5. Now AI Machines Are Learning to Understand Stories – MIT Technology Review – and not just accelerating, but getting deeper.
  6. Robots are coming for your job. That might not be bad news – good alternative insight from Laurie Penny.
  7. Pocket: Physicists Unleash AI to Devise Unthinkable Experiments – not surprisingly, a smart use of AI
  8. AI’s dueling definitions – O’Reilly Media – this highlights one of the problems with AI, and that it is it is a suitcase word (or term) and people fill it with what they want to fill it with
  9. A Neural Network Playground – a very nice tool to start working with AI
  10. Foxconn replaces ‘60,000 factory workers with robots’ – BBC News – there is no doubt in places like Foxconn, robots are taking jobs.
  11. 7 Steps to Mastering Machine Learning With Python – don’t be put off by this site’s design: there is good stuff here
  12. How Amazon Triggered a Robot Arms Race – Bloomberg – Amazon made a smart move with that acquisition and it is paying off
  13. When Police Use Robots to Kill People – Bloomberg this is a real moral quandary and I am certain the police aren’t the only people to be deciding on it. See also: A conversation on the ethics of Dallas police’s bomb robot – The Verge
  14. How to build and run your first deep learning network – O’Reilly Media – more good stuff on ML/DL/AI
  15. This expert thinks robots aren’t going to destroy many jobs. And that’s a problem. | The new new economy – another alternative take on robots and jobs
  16. Neural Evolution – Building a natural selection process with AI – more tutorials
  17. Uber Parking Lot Patrolled By Security Robot | Popular Science – not too long after this, one of these robots drowned in a pool in a mall. Technology: it’s not easy 🙂
  18. A Robot That Harms: When Machines Make Life Or Death Decisions : All Tech Considered : NPR – this is kinda dumb, but worth a quick read.
  19. Mathematics of Machine Learning | Mathematics | MIT OpenCourseWare – if you have the math skills, this looks promising
  20. Small Prolog | Managing organized complexity – I will always remain an AI/Prolog fan, so I am including this link.
  21. TensorKart: self-driving MarioKart with TensorFlow – a very cool application
  22. AI Software Learns to Make AI Software – MIT Technology Review – there is less here than it appears, but still worth reviewing
  23. How to Beat the Robots – The New York Times – meh. I think people need to learn to work with the technology, not try to defeat it. If you disagree, read this.
  24. People want to know: Why are there no good bots? – bot makers, take note.
  25. Noahpinion: Robuts takin’ jerbs
  26. globalinequality: Robotics or fascination with anthropomorphism – everyone is writing about robots and jobs, it seems.
  27. Valohai – more ML tools
  28. Seth’s Blog: 23 things artificially intelligent computers can do better/faster/cheaper than you can – like I said, everyone is writing about AI. Even Seth Godin.
  29. The Six Main Stories, As Identified by a Computer – The Atlantic – again, not a big deal, but interesting.
  30. A poet does TensorFlow – O’Reilly Media – artists will always experiment with new mediums
  31. How to train your own Object Detector with TensorFlow’s Object Detector API – more good tooling.
  32. Rise of the machines – the best – by far! – non-technical piece I have read about AI and robots.
  33. We Trained A Computer To Search For Hidden Spy Planes. This Is What It Found. – I was super impressed what Buzzfeed did here.
  34. The Best Machine Learning Resources – Machine Learning for Humans – Medium – tons of good resources here.